From nobody Tue Dec 1 01:12:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A2C1B3992 for ; Tue, 1 Dec 2015 01:12:53 -0800 (PST) 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 3ju4vy9fTFj5 for ; Tue, 1 Dec 2015 01:12:51 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B3C1B3994 for ; Tue, 1 Dec 2015 01:12:51 -0800 (PST) Received: by wmww144 with SMTP id w144so4011560wmw.0 for ; Tue, 01 Dec 2015 01:12:50 -0800 (PST) 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=kAJwnn2I1s7E0ZvHzcO5RY4L7XpFTwDgpi3jKDEHHyw=; b=mWA1Tw3HXNSFC7aCFgFIeZqcyak/FfZyA91BioG26XBjbhm95clE+V15214V0STIcF y/HskqhrA/qHKCJETgnVDmLlUMXL4dDp8DQT5sL6ZqCHyLRz6UxeJov9GJaFB03HSIO2 FUqhU7cGFffSPMtOLXKp1L+Q+F7E9rLW2BTlDiGqQIoTh3vQPHiIFjP+bxtR2Fm1N4dN Lr2tFfnUrYZ8opOWqB5A8BSwDhwWb8G2Rmoj3p72D+5k6EF8KSJIyFVOZxBWZyhirezs saewTSw+qvEpE/AHzmNr5RIWOvu3PhAdm977U7h8rmKJ+CK9W8+iGCRZ2Yqkysnbraf3 cqOw== X-Received: by 10.194.87.201 with SMTP id ba9mr43000126wjb.125.1448961169856; Tue, 01 Dec 2015 01:12:49 -0800 (PST) Received: from [172.24.248.183] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id n7sm25036897wmf.21.2015.12.01.01.12.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Dec 2015 01:12:48 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: Date: Tue, 1 Dec 2015 11:12:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B906BDF-CA30-4EDF-ADA9-ABFC2A25014D@gmail.com> References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> To: Jacob Appelbaum X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 09:12:53 -0000 > On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum = wrote: >=20 > On 12/1/15, Viktor Dukhovni wrote: >> On Mon, Nov 30, 2015 at 10:34:27AM +0000, Peter Gutmann wrote: >>=20 >>> Bryan A Ford writes: >>>=20 >>>> It would work just as well and in exactly the same way if the AEAD = is >>>> replaced with the traditional Encrypt-then-MAC construction, for >>>> example. >>>=20 >>> No it wouldn't, unless the encrypt part is a stream cipher. You're = still >>> locked into using an AEAD stream cipher or the equivalent of an AEAD >>> stream >>> cipher built with encrypt+MAC. It won't work with, for example, the = OCB >>> AEAD >>> mode, or CBC + MAC. >>=20 >> I think we should focus on what would get TLS 1.3 to be adopted: >>=20 >> * Reasonably implementable in libraries that support older >> versions alongside TLS 1.3. >>=20 >=20 > That doesn't change with Bryan's suggestion, I think. >=20 >> * Interoperable in the field with various capital-intensive >> middle boxen. >=20 > Which would those be? And what is the definition of capital-intensive > for those watching on the sidelines? Firewall, IPS/IDS devices. Boxes that attempt to perform sanity-check on = protocols to make sure that the stuff going over TCP port 443 is really = HTTPS rather than an attempt at tunneling. There are some attacks such = the the code that protects against them needs to follow TLS record = sizes. For the most part these are not-so-interesting attacks, causing = certain versions of certain browsers to hang, and they are expensive for = the firewall to protect against, so for the most part these protections = are turned off. But it=E2=80=99s not everywhere. If enough middleboxes block TLS 1.3, the browsers will implement a = downgrade dance. If they do that, attackers will be able to exploit the = downgrade dance. I don=E2=80=99t think the net effect is better = security. We=E2=80=99d be far better off writing a separate document on = how to use the padding feature that is already in 1.3 to mitigate = traffic analysis without actually flooding your Internet connection. = Splitting records and padding a few can be more effective than masking = the length bits. Yoav From nobody Tue Dec 1 03:02:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B61E1A8A3F for ; Tue, 1 Dec 2015 03:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-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 2AmsqTukAVqg for ; Tue, 1 Dec 2015 03:02:11 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8031A8A39 for ; Tue, 1 Dec 2015 03:02:10 -0800 (PST) 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 (Postfix) with ESMTPS id 3AFB1D69D9; Tue, 1 Dec 2015 11:02:10 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-114.brq.redhat.com [10.34.0.114]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB1B28Ho020672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Dec 2015 06:02:09 -0500 From: Hubert Kario To: Jacob Appelbaum Date: Tue, 01 Dec 2015 12:02:07 +0100 Message-ID: <8237123.IbIWt7fMrM@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.6-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: References: <56586A2F.1070703@gmail.com> <2564045.EyFMgGcPZE@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5991821.sbMHVJVuhf"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 11:02:13 -0000 --nextPart5991821.sbMHVJVuhf Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 01 December 2015 00:14:14 Jacob Appelbaum wrote: > On 11/30/15, Hubert Kario wrote: > > On Monday 30 November 2015 10:58:48 Bryan A Ford wrote: > >> On 11/30/15 2:40 AM, Peter Gutmann wrote: > >> > Nikos Mavrogiannopoulos writes: > >> >> I believe your proposal is a nice example of putting the cart > >> >> before the horse. Before proposing something it should be clear= > >> >> what do you want to protect from, what is the threat? > >> >=20 > >> > Exactly. If you want to thwart traffic analysis, you need to do= > >> > something like what's done by designs like Aqua ("Towards > >> > Efficient > >> > Traffic-analysis Resistant Anonymity Networks"), or ideas from > >> > any > >> > of the other anti-traffic- analysis work that's emerged in the > >> > past > >> > decade or two. > >>=20 > >> I'm well aware of Aqua and "the other anti-traffic-analysis work > >> that's emerged in the past decade or two": in fact I led one of th= e > >>=20 > >> major recent systematic projects in that space. See for example: > >> =09http://dedis.cs.yale.edu/dissent/ > >> =09http://cacm.acm.org/magazines/2015/10/192387-seeking-anonymity-= in-> >> =09an->>>=20 > >> internet-panopticon/fulltext > >>=20 > >> > You get traffic > >> > analysis resistance by, for example, breaking data into > >> > fixed-length > >> > packets, using cover traffic, and messing with packet timings, > >> > not > >> > by > >> > encrypting TLS headers. > >>=20 > >> Packet padding and header encryption are both important, > >> complementary security measures: you get security benefits from > >> each that you don't get from the other. Yes, you need padding to > >> obtain systematic protection from traffic analysis - when for > >> whatever reason not all implementations are always padding to the > >> exact same standardized record length, header encryption makes > >> padded streams less trivially distinguishable from unpadded > >> streams, and makes streams with different record sizes less > >> trivially distinguishable from each other. > >=20 > > the header contains only one piece of information, and it is public= > > already - the amount of data transmitted* >=20 > I'm pretty sure TLS has a lot more data... in TLS v1.3 no, it doesn't. All encrypted packets must have the=20 plaintext record type set to Application Data[1], same for version -=20= it's frozen now at 3.1 (TLS1.0)[2], both are used just as a magic value= . > > this goes well past the TLS WG charter, if only because it requires= > > very close cooperation with the application layer > >=20 > > so while the padding mechanism should be there, we really can't > > describe how it needs to be used, as it can't be made universal nor= > > is it necessary for all use cases >=20 > I think it should be described how it needs to be used... Yes, I misspoke. What I meant is that we can't mandate its use as it is= =20 an application layer issue. We definitely should describe how it needs=20= to be used on TLS level. > > * - sure, the record layer boundaries can tell something about the= > > data>=20 > > being transmitted, but so can the presence of data transmission > > taking place in the first place (think of a station sending reports= > > only when it detects something while keeping connection open the > > whole time) > Yes, they tell something and that something is better removed. then we need Best Current Practice for applications describing to them=20= how TLS needs to be used, e.g. make sure that they are doing writes as=20= big as possible, checking if timing of responses doesn't leak much=20 information, etc. Forcing TLS implementation to combine writes will=20 easily cause serious problems with interactivity of sessions... > >> One thing that would greatly help Tor and all similar, > >> padded protocols is if they could "blend in" even just a little bi= t > >> better with the vast bulk of ordinary TLS-encrypted Web traffic, > >> and > >> that's one of the big opportunities we're talking about here. > >=20 > > the initial message in handshake in TLS MUST stay the same thus it > > is > > impossible to make it look like Tor. Not to thwart the Pervasive > > Monitoring threat of TLA agencies. >=20 > That Tor claim is strange and seemingly false in any case. Also, I've= > said it before quoting the RFC but I'll say it again: Pervasive > Monitoring is an attack. Not claiming it isn't. But some things (like compression) are best done= =20 at application layer, not TLS layer. =20 > >> If you think it is practical for the TLS 1.3 standard to specify a= > >> single, fixed record size that all implementations of TLS 1.3 must= > >> use (i.e., explicitly freeze not only the version field but the > >> length field), then that would be great for traffic analysis > >> protection and on that basis I would support that proposal. But > >> that frankly seems to me likely a bit too much to ask given the > >> diversity of TLS implementations and use-cases. Tell me if you > >> believe otherwise.>=20 > > That will just round up to a multiple of 256 bytes the data sizes > > transmitted. Hardly an improvement over the current 16 byte blocks.= >=20 > Closer to 512 bytes is better. Either hardly helps if you're not transferring packets with null data t= o=20 really hide the amount of data transferred. 1 - https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-5.2.2 opaque_type The outer opaque_type field of a TLSCiphertext record is always set to the value 23 (application_data) for outward compatibility with middleboxes used to parsing previous versions of TLS. The actual content type of the record is found in fragment.type after= decryption. 2 - https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-5.2.2 record_version The record_version field is identical to TLSPlaintext.record_version and is always { 3, 1 }. Note that th= e handshake protocol including the ClientHello and ServerHello messages authenticates the protocol version, so this value is redundant. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart5991821.sbMHVJVuhf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJWXX4vAAoJEJKo0bgB0vX19fgQAIvf/jNEn/y3Wy+zYCbLwGUN xDkVqlg/54Y/NFYCGESNBtig5YlOz62rBWK/6QhNdqsF6yFyFw+I+8yEgsco8aFI A4NfQRxMRnRGh3vSkJV0DJEwTCTBe7cYuBVD434+lI758Z6L5ldb2dVu08UHyU3r MKwXFG0GD0dwxliEb6Ce19DVriByMGwOn3b2/kDeJrzo602JG+QVYmeWLtZUyGvC aGoFmDd+yHCV03kXjINCL/KCPH7f44kagp34sOa5jPfJ+ssZT+FAub2gZkbK9RFD 04EivvwfVxVx4OfGl56AYKUd/HavdV7wbv5vCJ7UU94Us2J88x85XRtmWIaQZTq2 T4S2F9e0KTjuKg0nF7TKBlJTZmOpN9GByn14Bxk7QoGMUgyVP+v0K/nHwafeX+qK 5ZHmlAAxKKKwHZsxPpIVVDCUq680fYt7eSFsn6Yzb13XgdQP/yuuWuI+xTwfZkj1 4hfZh/S5rr0fB4mtDFbXxUwlWLdnJkjrMaqJbzD2xjSJ+VSp6XQjK41NKcUKObqZ RUKvXUe44Nnow51DQDdPTjCEqI9/zvwhoMKz1OA2/7N15T6A4tK+4H2mnF/BEwoo VvgoipHZr7rssgTh28dOeTerH5OIxtoHN3NbP0ONIXZD6+9M7z68s9Feapgkc581 jL1gkbixAc03eDT98Xit =h52w -----END PGP SIGNATURE----- --nextPart5991821.sbMHVJVuhf-- From nobody Tue Dec 1 04:17:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCEE1B2B69 for ; Tue, 1 Dec 2015 04:17:41 -0800 (PST) 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 OS_1vUq_Etre for ; Tue, 1 Dec 2015 04:17:40 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D3E61B2B18 for ; Tue, 1 Dec 2015 04:17:40 -0800 (PST) Received: by vkbs1 with SMTP id s1so2416967vkb.1 for ; Tue, 01 Dec 2015 04:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=RSiJOAimdest1vqbCsZlZG/++hmEOt5Y8LWLzq61w0I=; b=frXmWnjB/8dI9D+Ihj/0xmVk0IZOaAYL97BEwfHsLd2GKWf0pdI0Y/+Cm7VROtXfUk fNHRMbz6t9GRkA3wTAAM051PAvQvvfc/lLLXSUXv0rnbB09SKwGcKd7mmzITWC//tTET adHp0r0yH1zVEksdprqqh+tIMfT+s0wSGT/Ks= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=RSiJOAimdest1vqbCsZlZG/++hmEOt5Y8LWLzq61w0I=; b=Cu2249miklyWvhyFLDsLuIUOGvabdX1wujdUmPka0WWePZEOVyv8snWkxzqN6g/cQh QCjVX6xE1VWrmb4+Yjsbm3M8HEDO3E1VF5EGv0P4hShONML75JXPnYn79SxnJv/uSLIc x+apFbCLK0mH3y8cRawjF/XhIGC3DyUv45pyeHe6rc6w1msczGtyHOFwNsf89Umi0zfi 9725sWBrV+UkGmqh/LQY0TqFXcxilu+hdRvZtpCvJopA0JxMoUHnGWHgmZG0bW8V6/a4 kqn6jN7X+WUV/g29VbJSFDDXokfQmrDhM74qahydI0p0kHbmN9t9LNydizzD/tcpNN91 6cfA== X-Gm-Message-State: ALoCoQlE7Ge8BUaPLO9D5Sg0GG1nO8cL5vZ3r8Omf9m1VF4FNculGwCASpNJgJrzkRItG0ZMhw/s X-Received: by 10.31.8.8 with SMTP id 8mr54032037vki.106.1448972259293; Tue, 01 Dec 2015 04:17:39 -0800 (PST) From: William Whyte References: <201511301627.27616.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQICwOAW+N1Vhz9XpHHvMpg7SRjaKQH9ulKSAaXd/32eNcXEAA== Date: Tue, 1 Dec 2015 07:17:40 -0500 Message-ID: To: Tony Arcieri , Hugo Krawczyk Content-Type: multipart/alternative; boundary=001a11454c64ce12e70525d52419 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] bikeshed: Forward Security or Secrecy? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 12:17:41 -0000 --001a11454c64ce12e70525d52419 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If we want to change to =E2=80=9Ckey erasure=E2=80=9D we should synch with = CFRG and SAAG to ensure it=E2=80=99s used IETF-wide. I don=E2=80=99t think that =E2=80=9Cfor= ward secrecy=E2=80=9D is so broken that it needs fixing. Cheers, William *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Tony Arcieri *Sent:* Monday, November 30, 2015 11:20 PM *To:* Hugo Krawczyk *Cc:* tls@ietf.org *Subject:* Re: [TLS] bikeshed: Forward Security or Secrecy? On Mon, Nov 30, 2015 at 8:09 PM, Hugo Krawczyk wrote: The more common term is "forward secrecy" I'd second this. I'm also a fan of Dan Bernstein's recommended term: "key erasure" --=20 Tony Arcieri --001a11454c64ce12e70525d52419 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

If= we want to change to =E2=80=9Ckey erasure=E2=80=9D we should synch with CF= RG and SAAG to ensure it=E2=80=99s used IETF-wide. I don=E2=80=99t think th= at =E2=80=9Cforward secrecy=E2=80=9D is so broken that it needs fixing.

=C2=A0

<= p class=3D"MsoNormal">Cheers,

=C2=A0

William

= =C2=A0

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Tony Arcieri
= Sent: Monday, November 30, 2015 11:20 PM
To: Hugo Krawczyk=
Cc: tls@ietf.org
Subje= ct: Re: [TLS] bikeshed: Forward Security or Secrecy?

=C2=A0

On Mon, Nov = 30, 2015 at 8:09 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:

=

The more common term is "forward secrecy"

=C2=A0

I'd second this. I'm also a fan of Dan Bernstein'= ;s recommended term: "key erasure" =C2=A0

=C2=A0

--

Tony Arcieri

--001a11454c64ce12e70525d52419-- From nobody Tue Dec 1 05:15:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347E21B2D20 for ; Tue, 1 Dec 2015 05:15:09 -0800 (PST) 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] 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 4AXDM2scqoUa for ; Tue, 1 Dec 2015 05:15:07 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EAB01B2D15 for ; Tue, 1 Dec 2015 05:15:07 -0800 (PST) Received: by lfaz4 with SMTP id z4so7553145lfa.0 for ; Tue, 01 Dec 2015 05:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=J1puTTTmuEtUbgHdRCwFbgYRbXV60tn6x+vNQ1/AinU=; b=d0iIzinkM+0u1ByhDQLBl53UJ9l32BRxid/dPeSDZSbITGORrPkxbH9mLPQtnhSetq Gz0OejTaR7RkPpHSDSgGWg99BzEf6+9JaY/y7M/p+Qqp3cgIJY47y0VXg765EK9tTEQc alyEfwT8UGMFbS15gPuSmQoPJGMBu2GK7rSyU= 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; bh=J1puTTTmuEtUbgHdRCwFbgYRbXV60tn6x+vNQ1/AinU=; b=TXYk58rP50I7w+2Dl4L+1xwW1XOxYnujRXi5SuACtwl/NHFhY8fy8sRkFOw7SQGJ43 wDmTUUwP18OcRJ3IbbESuIzsANP4JuVD0juUFy8TFiCEhkYsoaQS9c8xpZz4pmQ4XnQu 88E7jxnR4Lkn34drDj0F4VmIk6KQ+enq67cMQJxiMg8/Ye7MgRFrWHdoi4V72cxIJ6hS 56P5z3Q8kAMKCoTEROdBqiY2CzDhAjl7558llQ68M1GudObJFZc+Nv+x1beiOujXcMcf bqI8q1+N75+P9LOYSU1I1xQG5UqLdNYAEGTM+xj8p01H2kmW8z8BEEqzolY97whDmuGx z2qw== X-Gm-Message-State: ALoCoQmyrPVQHVyySSSQoFb8uD9OlWc9F3PV100nXT2+cEjhbkivpTP21zrwgIjDjGpE0sSfPCWM X-Received: by 10.112.129.98 with SMTP id nv2mr17392953lbb.17.1448975705447; Tue, 01 Dec 2015 05:15:05 -0800 (PST) Received: from [192.168.1.117] ([41.232.114.68]) by smtp.gmail.com with ESMTPSA id sv10sm5387127lbb.46.2015.12.01.05.15.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Dec 2015 05:15:04 -0800 (PST) Message-ID: <565D9D54.1050100@azet.org> Date: Tue, 01 Dec 2015 14:15:00 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Hubert Kario References: <56586A2F.1070703@gmail.com> <2564045.EyFMgGcPZE@pintsize.usersys.redhat.com> <8237123.IbIWt7fMrM@pintsize.usersys.redhat.com> In-Reply-To: <8237123.IbIWt7fMrM@pintsize.usersys.redhat.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig0CA8B1857FF51B7DC1BBB37D" Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 13:15:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0CA8B1857FF51B7DC1BBB37D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Hubert Kario wrote: > then we need Best Current Practice for applications describing to them = > how TLS needs to be used, e.g. make sure that they are doing writes as = > big as possible, checking if timing of responses doesn't leak much=20 > information, etc. Forcing TLS implementation to combine writes will=20 > easily cause serious problems with interactivity of sessions... >=20 FYI: similar IETF documents like that exists for TLS (up to 1.2) already. Might make sense to update them or have similar ones when time comes. Though spreading everything out over a lot of documents makes it harder for implementers to find all the information they might be looking for, IMO. Actually, as far as I understand the whole objective of UTA-WG is putting out documents like that (Utilizing TLS in Applications). https://tools.ietf.org/html/rfc7457 https://tools.ietf.org/html/rfc7525 Aaron --------------enig0CA8B1857FF51B7DC1BBB37D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWXZ1VAAoJEOTbZJL9ubXVOhYP/A6CsHBDytm/MJFbrB6WfA6G MHy8BJdJhPk6wGmL2x1vC1AMPWGDY3lfk5YrRu0urvqy8OxUNcUHiABGOu67lene sUQY4OjbsuUUqHQn/7tkoaye3rDUPkDMtwP0yhKfzRU5o6CO7BB28eI4JKgOrtxQ v94kLB33qSIzAan/lF/hLUGreCKC5+bd7LP//JAWfa7jxDKhQ8spVFbJ6mi4SsjO 30xLpblQFnsCf0jNGk2UtBSGyIrlVs1qjQh/AvFxZ3wHDGWOp0kgwh+irR32CAVk ERM0wkKL+4f4BywoBKfnONI0Y50aAon03DIsqGWfNYJm6FHUcqFvjNur9oXYyD3I 3L2oNz64rVttHyyjMdvqqU3UtMCZ9YeH7EBWmjQwvhcW0QlhwzKNtTbNqMCAUHCj ouQfjfwyqAwpyP82sjKMyyTJ7JdzNPu3CBpqTih/QM5SqqgV2FFuNbYac6tI1utY mt3Eyih3H+pzPsRUcljYF2pBcemdLlYE4fxScZ6F/dYhSiOWCMnCZTx4Xe6Wi4n0 8uNK4vSFDvERi6aynIuDHsnfHigB/YHRF4FoYvRsB0rwosuITM97AfWbXVeMgM5s mnO9VoTB2Mu9gGW/0kZmY8ytjOfECbgE/rjrmpU7pX6vazTSoeGNE2Mu0CoFCQNX h7R5T6vT8Z0azmC7Gc/+ =RGWj -----END PGP SIGNATURE----- --------------enig0CA8B1857FF51B7DC1BBB37D-- From nobody Tue Dec 1 05:40:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173D81B2D9D for ; Tue, 1 Dec 2015 05:40:57 -0800 (PST) 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, HTML_MESSAGE=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 ziOWFGoXhER7 for ; Tue, 1 Dec 2015 05:40:55 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADDA71B2D9C for ; Tue, 1 Dec 2015 05:40:54 -0800 (PST) Received: by ykdr82 with SMTP id r82so6769755ykd.3 for ; Tue, 01 Dec 2015 05:40:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gxlnA/dtj8tkhmlAfLfz4ERhaNS49eieM2F910XvAqY=; b=FondM46NsFbS6AbpqPjAgelsnDey+krqwPjQ7K6wLt3tSkvUTeT3cwj+pAkmW1cyYL pQzYwfTpgnSRDOXJHf82o+ukhTz3vJtBpMGdkIeA2q8iiZhwyRu6fDUyb6XomTxArtDs glgwm5dwk8BormWf5wyHJ9USXQRZZ4ukoH0CRDXhNlDbc+m8Kno1TIa771LA5paB6GJL +KYFaN6M3hEVtf9mJqHrYCYWYkg66E8F9trVf9LALXGqEmXmxrhSxQbrXJZhZ4ZxTzz3 mTSb74xhgFZcbIMEJV7EelQCNZPasOmSNlcoWATrZBytLvgwHcfsfUBpMcAgEoFrQ/Hx 0cVQ== 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=gxlnA/dtj8tkhmlAfLfz4ERhaNS49eieM2F910XvAqY=; b=lqZ8Evh3+SPOiyFP3T8OjEkosRQWIbav+5isrixx+cBAQugDAFhLRFkCdn6E0xfDfP va0xFoRv6VRVCqOG7An78A6psfVe4Hmh9luKciHTgguxBJoxTdkMiS2p1WUcb5MJ+hFE 35T7Z55MFlmWzQXMm6v+B1liXUilJZGvw3QUoX/SQM11V9992aA/7tpB84FQb4nTY1bi D0h3XKZuy8Pa9VOQ4trZiYvrTNs7i8qyYwUWTJDrvfDqbnkOyfCmV4uaf9vHG03axbdF n+ZUKMU51e5jGxPP811auanvJsf/xJlfK1SPcGadCsvA+MPVU/ZYOHOQgidvNTMU3Crn jOfw== X-Gm-Message-State: ALoCoQmpoox8mUTUZmG3TBTeenJkHp2bNLLr2oHAQgCxMYyMPJLnr6H/qgxqimSX9+S47lO9uPCk X-Received: by 10.129.79.11 with SMTP id d11mr27535770ywb.115.1448977254000; Tue, 01 Dec 2015 05:40:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 1 Dec 2015 05:40:14 -0800 (PST) In-Reply-To: References: <201511301627.27616.davemgarrett@gmail.com> From: Eric Rescorla Date: Tue, 1 Dec 2015 05:40:14 -0800 Message-ID: To: William Whyte Content-Type: multipart/alternative; boundary=001a114dbab0835c060525d64e22 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] bikeshed: Forward Security or Secrecy? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 13:40:57 -0000 --001a114dbab0835c060525d64e22 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am planning to use "forward secrecy" On Tue, Dec 1, 2015 at 4:17 AM, William Whyte wrote: > If we want to change to =E2=80=9Ckey erasure=E2=80=9D we should synch wit= h CFRG and SAAG > to ensure it=E2=80=99s used IETF-wide. I don=E2=80=99t think that =E2=80= =9Cforward secrecy=E2=80=9D is so > broken that it needs fixing. > > > > Cheers, > > > > William > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Tony Arcieri > *Sent:* Monday, November 30, 2015 11:20 PM > *To:* Hugo Krawczyk > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] bikeshed: Forward Security or Secrecy? > > > > On Mon, Nov 30, 2015 at 8:09 PM, Hugo Krawczyk > wrote: > > The more common term is "forward secrecy" > > > > I'd second this. I'm also a fan of Dan Bernstein's recommended term: "key > erasure" > > > > -- > > Tony Arcieri > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114dbab0835c060525d64e22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am planning to use "forward secrecy"

On Tue, Dec 1, 2015 a= t 4:17 AM, William Whyte <wwhyte@securityinnovation.com>= ; wrote:

If we want to change to =E2=80=9Ckey erasure=E2=80=9D we should sync= h with CFRG and SAAG to ensure it=E2=80=99s used IETF-wide. I don=E2=80=99t= think that =E2=80=9Cforward secrecy=E2=80=9D is so broken that it needs fi= xing.

=C2=A0

Cheers,

=C2=A0

William

=C2=A0

From: TLS [mailto:tls-bounces@ietf.org] On Beh= alf Of Tony Arcieri
Sent: Monday, November 30, 2015 11:20 PM<= br>To: Hugo Krawczyk
Cc: tls@ietf.org
Subject: Re: [TLS] bikeshed: Fo= rward Security or Secrecy?

=C2=A0

On Mon, Nov 30, 201= 5 at 8:09 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:

The more common term is "forward secrecy"

<= /div>

=C2=A0

I'd second this. I'm also a fan of Dan Bernstein's reco= mmended term: "key erasure" =C2=A0

=C2=A0

--

Tony Arcieri


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


--001a114dbab0835c060525d64e22-- From nobody Tue Dec 1 06:22:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473C31A0AFE for ; Tue, 1 Dec 2015 06:22:32 -0800 (PST) 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 ZyvALimPYyVJ for ; Tue, 1 Dec 2015 06:22:29 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C451A1A62 for ; Tue, 1 Dec 2015 06:22:27 -0800 (PST) Received: by wmvv187 with SMTP id v187so209096490wmv.1 for ; Tue, 01 Dec 2015 06:22:26 -0800 (PST) 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=QB91p/iGM2qMlkp1vDp9V+ystd3sNV7E6vkQOsOszmM=; b=a1rd0CxbnwbQfGDPO5mDqzDE8zERvd6OyAmOIUkxYWNzDrzLWn6ZwKx1IkptYFKGp+ dhvdclfV5tzWrewUYZ0gdxdvMxeg1JXXviLzSzEPl+Zybt/Ol5KKjaxIJ7hJVSLF04vm P/fZADepILmWVTVAECIyl7Gc0oypgIJ/WOpt51uHMRl6iuPmvyAmRYeaCnuE8XQBfCj/ qvDdYhxZuFttBc+S+5YzY4xO7zfprnAxvSvyHw2PmhjOmBsBTtBH4FnTS7AqvtAdzvN2 cr1gITnTDvniLsYPhJOhaDq+OUMPUkqPyG153OG/6SRNwgZsXdBd7y4chX6XZ2ejRb1V /2Cw== X-Received: by 10.194.87.201 with SMTP id ba9mr44900701wjb.125.1448979746439; Tue, 01 Dec 2015 06:22:26 -0800 (PST) Received: from [172.24.248.183] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id jj3sm284692wjb.13.2015.12.01.06.22.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Dec 2015 06:22:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <8237123.IbIWt7fMrM@pintsize.usersys.redhat.com> Date: Tue, 1 Dec 2015 16:22:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <63861B5E-FF23-4A8E-A755-D4729FB1FCCB@gmail.com> References: <56586A2F.1070703@gmail.com> <2564045.EyFMgGcPZE@pintsize.usersys.redhat.com> <8237123.IbIWt7fMrM@pintsize.usersys.redhat.com> To: Hubert Kario X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 14:22:32 -0000 On 1 Dec 2015, at 1:02 PM, Hubert Kario wrote: >>>> If you think it is practical for the TLS 1.3 standard to specify a >>>> single, fixed record size that all implementations of TLS 1.3 must >>>> use (i.e., explicitly freeze not only the version field but the >>>> length field), then that would be great for traffic analysis >>>> protection and on that basis I would support that proposal. But >>>> that frankly seems to me likely a bit too much to ask given the >>>> diversity of TLS implementations and use-cases. Tell me if you >>>> believe otherwise.>=20 >>> That will just round up to a multiple of 256 bytes the data sizes >>> transmitted. Hardly an improvement over the current 16 byte blocks. >>=20 >> Closer to 512 bytes is better. >=20 > Either hardly helps if you're not transferring packets with null data = to=20 > really hide the amount of data transferred. I think this is not as black and white as you suggest.=20 It is possible to totally hide the actual data stream by sending a = constant-rate stream of constant-size data records regardless of the = availability of actual data. This is a perfect counter-measure to = traffic analysis but it has a huge cost in bandwidth. Endpoints who do = that might well be considered to be DoS-ing the network.=20 There are less drastic ways. You could add small variations to the = timing and sizes of records, adding a little padding, splitting and = combining the application writes, perhaps with the addition of the = occasional burst of fake traffic. This can have a relatively small = overhead and obscure the real sizes and number of requests. An attacker = will still have an approximation of the amount of real traffic is = actually passed, but would not be able to guess which Wikipedia article = you are viewing or what part of the world you are looking at with your = favorite maps website. This is not as perfect as the full traffic flow = confidentiality above, but it would be more palatable to network = administrators and to people who pay for Internet access by the = megabyte. I don=E2=80=99t think this is the same as encryption where you either = have perfect security or you have nothing at all. There can be = incremental gains that are worth having at significantly lower cost than = the perfect TFC. Yoav From nobody Tue Dec 1 06:53:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073891A92E2 for ; Tue, 1 Dec 2015 06:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6h5luvhVn_Dm for ; Tue, 1 Dec 2015 06:53:20 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD89F1A92DE for ; Tue, 1 Dec 2015 06:53:19 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-b4-565db45deb4b Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 88.2F.05149.D54BD565; Tue, 1 Dec 2015 15:53:17 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.72]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Tue, 1 Dec 2015 15:53:17 +0100 From: John Mattsson To: Yoav Nir , Hubert Kario Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all? Thread-Index: AQHRLEgC9Fvj7xSjPUCCuObZgYMa+g== Date: Tue, 1 Dec 2015 14:53:16 +0000 Message-ID: References: <56586A2F.1070703@gmail.com> <2564045.EyFMgGcPZE@pintsize.usersys.redhat.com> <8237123.IbIWt7fMrM@pintsize.usersys.redhat.com> <63861B5E-FF23-4A8E-A755-D4729FB1FCCB@gmail.com> In-Reply-To: <63861B5E-FF23-4A8E-A755-D4729FB1FCCB@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-ID: <907513AAA8DC544EBF9953FCA715E605@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2K7mW7sltgwg+UHtC1ufTvMavHpfBej xdJjH5gcmD12zrrL7rFkyU8mj/f7rrIFMEdx2aSk5mSWpRbp2yVwZVw8/4S14J58xaKn59ka GL/IdTFyckgImEicWLeAHcIWk7hwbz1bFyMXh5DAYUaJzQePgSWEBBYxSjy9WQNiswkYSMzd 08AGYosIuEj86NvBCmIzCyhKvL80jwXEFhYIkLjXsYsZoiZQ4lVDI1CcA8jWk+i+ZA0SZhFQ kTi3uosRxOYVMJdYvWUKI8TeDiaJAxf3gfVyCthK7G7bzwRiMwId9/3UGiaIXeISt57MZ4I4 WkBiyZ7zzBC2qMTLx//A7hEF2nXw00pWiLiixMdX+xhBbmAW0JRYv0sfYoy1xJKuuUww50/p fsgOcY+gxMmZT1gmMErMQrJtFkL3LCTds5B0z0LSvYCRdRWjaHFqcVJuupGRXmpRZnJxcX6e Xl5qySZGYFwe3PLbYAfjy+eOhxgFOBiVeHg/XIkJE2JNLCuuzD3EKMHBrCTC+3RtbJgQb0pi ZVVqUX58UWlOavEhRmkOFiVx3mamB6FCAumJJanZqakFqUUwWSYOTqkGxlUzHPda87+8s2Lf oWm73s65ll8X558fF8jRd+5BzdZVn9cr/l+ewC/5yI09IXeFk1is9GHDJRMqprx4+OZMbELQ +SNbLNkLLllsOdnaPom1tXV11PYrIU92C+ckm9wQ91TruPnKjJnLXsok4mbcT8nC3423F8tG 8eiEOelzSpfXK/zeIbDxlxJLcUaioRZzUXEiACSaCV/HAgAA Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 14:53:23 -0000 DQpPbiAwMS8xMi8xNSAxNToyMiwgIlRMUyBvbiBiZWhhbGYgb2YgWW9hdiBOaXIiIDx0bHMtYm91 bmNlc0BpZXRmLm9yZyBvbg0KYmVoYWxmIG9mIHluaXIuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0K DQo+DQo+T24gMSBEZWMgMjAxNSwgYXQgMTowMiBQTSwgSHViZXJ0IEthcmlvIDxoa2FyaW9AcmVk aGF0LmNvbT4gd3JvdGU6DQo+DQo+Pj4+PiBJZiB5b3UgdGhpbmsgaXQgaXMgcHJhY3RpY2FsIGZv ciB0aGUgVExTIDEuMyBzdGFuZGFyZCB0byBzcGVjaWZ5IGENCj4+Pj4+IHNpbmdsZSwgZml4ZWQg cmVjb3JkIHNpemUgdGhhdCBhbGwgaW1wbGVtZW50YXRpb25zIG9mIFRMUyAxLjMgbXVzdA0KPj4+ Pj4gdXNlIChpLmUuLCBleHBsaWNpdGx5IGZyZWV6ZSBub3Qgb25seSB0aGUgdmVyc2lvbiBmaWVs ZCBidXQgdGhlDQo+Pj4+PiBsZW5ndGggZmllbGQpLCB0aGVuIHRoYXQgd291bGQgYmUgZ3JlYXQg Zm9yIHRyYWZmaWMgYW5hbHlzaXMNCj4+Pj4+IHByb3RlY3Rpb24gYW5kIG9uIHRoYXQgYmFzaXMg SSB3b3VsZCBzdXBwb3J0IHRoYXQgcHJvcG9zYWwuICBCdXQNCj4+Pj4+IHRoYXQgZnJhbmtseSBz ZWVtcyB0byBtZSBsaWtlbHkgYSBiaXQgdG9vIG11Y2ggdG8gYXNrIGdpdmVuIHRoZQ0KPj4+Pj4g ZGl2ZXJzaXR5IG9mIFRMUyBpbXBsZW1lbnRhdGlvbnMgYW5kIHVzZS1jYXNlcy4gIFRlbGwgbWUg aWYgeW91DQo+Pj4+PiBiZWxpZXZlIG90aGVyd2lzZS4+DQo+Pj4+IFRoYXQgd2lsbCBqdXN0IHJv dW5kIHVwIHRvIGEgbXVsdGlwbGUgb2YgMjU2IGJ5dGVzIHRoZSBkYXRhIHNpemVzDQo+Pj4+IHRy YW5zbWl0dGVkLiBIYXJkbHkgYW4gaW1wcm92ZW1lbnQgb3ZlciB0aGUgY3VycmVudCAxNiBieXRl IGJsb2Nrcy4NCj4+PiANCj4+PiBDbG9zZXIgdG8gNTEyIGJ5dGVzIGlzIGJldHRlci4NCj4+IA0K Pj4gRWl0aGVyIGhhcmRseSBoZWxwcyBpZiB5b3UncmUgbm90IHRyYW5zZmVycmluZyBwYWNrZXRz IHdpdGggbnVsbCBkYXRhDQo+PnRvIA0KPj4gcmVhbGx5IGhpZGUgdGhlIGFtb3VudCBvZiBkYXRh IHRyYW5zZmVycmVkLg0KPg0KPkkgdGhpbmsgdGhpcyBpcyBub3QgYXMgYmxhY2sgYW5kIHdoaXRl IGFzIHlvdSBzdWdnZXN0Lg0KPg0KPkl0IGlzIHBvc3NpYmxlIHRvIHRvdGFsbHkgaGlkZSB0aGUg YWN0dWFsIGRhdGEgc3RyZWFtIGJ5IHNlbmRpbmcgYQ0KPmNvbnN0YW50LXJhdGUgc3RyZWFtIG9m IGNvbnN0YW50LXNpemUgZGF0YSByZWNvcmRzIHJlZ2FyZGxlc3Mgb2YgdGhlDQo+YXZhaWxhYmls aXR5IG9mIGFjdHVhbCBkYXRhLiBUaGlzIGlzIGEgcGVyZmVjdCBjb3VudGVyLW1lYXN1cmUgdG8g dHJhZmZpYw0KPmFuYWx5c2lzIGJ1dCBpdCBoYXMgYSBodWdlIGNvc3QgaW4gYmFuZHdpZHRoLiBF bmRwb2ludHMgd2hvIGRvIHRoYXQgbWlnaHQNCj53ZWxsIGJlIGNvbnNpZGVyZWQgdG8gYmUgRG9T LWluZyB0aGUgbmV0d29yay4NCj4NCj5UaGVyZSBhcmUgbGVzcyBkcmFzdGljIHdheXMuIFlvdSBj b3VsZCBhZGQgc21hbGwgdmFyaWF0aW9ucyB0byB0aGUgdGltaW5nDQo+YW5kIHNpemVzIG9mIHJl Y29yZHMsIGFkZGluZyBhIGxpdHRsZSBwYWRkaW5nLCBzcGxpdHRpbmcgYW5kIGNvbWJpbmluZw0K PnRoZSBhcHBsaWNhdGlvbiB3cml0ZXMsIHBlcmhhcHMgd2l0aCB0aGUgYWRkaXRpb24gb2YgdGhl IG9jY2FzaW9uYWwgYnVyc3QNCj5vZiBmYWtlIHRyYWZmaWMuIFRoaXMgY2FuIGhhdmUgYSByZWxh dGl2ZWx5IHNtYWxsIG92ZXJoZWFkIGFuZCBvYnNjdXJlDQo+dGhlIHJlYWwgc2l6ZXMgYW5kIG51 bWJlciBvZiByZXF1ZXN0cy4gQW4gYXR0YWNrZXIgd2lsbCBzdGlsbCBoYXZlIGFuDQo+YXBwcm94 aW1hdGlvbiBvZiB0aGUgYW1vdW50IG9mIHJlYWwgdHJhZmZpYyBpcyBhY3R1YWxseSBwYXNzZWQs IGJ1dCB3b3VsZA0KPm5vdCBiZSBhYmxlIHRvIGd1ZXNzIHdoaWNoIFdpa2lwZWRpYSBhcnRpY2xl IHlvdSBhcmUgdmlld2luZyBvciB3aGF0IHBhcnQNCj5vZiB0aGUgd29ybGQgeW91IGFyZSBsb29r aW5nIGF0IHdpdGggeW91ciBmYXZvcml0ZSBtYXBzIHdlYnNpdGUuIFRoaXMgaXMNCj5ub3QgYXMg cGVyZmVjdCBhcyB0aGUgZnVsbCB0cmFmZmljIGZsb3cgY29uZmlkZW50aWFsaXR5IGFib3ZlLCBi dXQgaXQNCj53b3VsZCBiZSBtb3JlIHBhbGF0YWJsZSB0byBuZXR3b3JrIGFkbWluaXN0cmF0b3Jz IGFuZCB0byBwZW9wbGUgd2hvIHBheQ0KPmZvciBJbnRlcm5ldCBhY2Nlc3MgYnkgdGhlIG1lZ2Fi eXRlLg0KPg0KPkkgZG9u4oCZdCB0aGluayB0aGlzIGlzIHRoZSBzYW1lIGFzIGVuY3J5cHRpb24g d2hlcmUgeW91IGVpdGhlciBoYXZlDQo+cGVyZmVjdCBzZWN1cml0eSBvciB5b3UgaGF2ZSBub3Ro aW5nIGF0IGFsbC4gVGhlcmUgY2FuIGJlIGluY3JlbWVudGFsDQo+Z2FpbnMgdGhhdCBhcmUgd29y dGggaGF2aW5nIGF0IHNpZ25pZmljYW50bHkgbG93ZXIgY29zdCB0aGFuIHRoZSBwZXJmZWN0DQo+ VEZDLg0KPg0KPllvYXYNCg0KV2hpbGUgSSBzdXBwb3J0IGFueXRoaW5nIGluY3JlYXNpbmcgcHJp dmFjeSwgSSB0aGluayBhIHRyYWZmaWMgZmxvdw0KY29uZmlkZW50aWFsaXR5IG1lY2hhbmlzbSBz aG91bGQgYmUgb3B0aW9uYWwgdG8gdXNlIChsaWtlIGluIEVTUCBSRkM0MzAzKSwNCmFuZCBub3Qg bWFuZGF0b3J5IHRvIHVzZS4gVGhlIGFyZSBzdGlsbCBtYW55IHVzZSBjYXNlcyB3aGVyZSB3aGVy ZQ0KYmFuZHdpZHRoIGlzIG5vdCBhYnVuZGFudCwgZS5nLiBtYW55IHdpcmVsZXNzIG5ldHdvcmtz IHN1Y2ggYXMgMkcsIDNHLA0KODAyLjE1LjQuIFBhZGRpbmcgYW5kIGR1bW15IHBhY2tldHMgbWF5 IHNpZ25pZmljYW50bHkgaW5jcmVhc2UgdGhlIG51bWJlcg0Kb2YgYnl0ZXMuIFdlIHNob3VsZCBu b3QgZW5kIHVwIGluIHNjZW5hcmlvIHdoZXJlIEQoVExTKSAxLjMgaXMgbm90IHVzZWQgaW4NCnNv bWUgc2NlbmFyaW9zIGJlY2F1c2Ugb2YgYW4gaW5jcmVhc2UgaW4gb3ZlcmhlYWQuDQoNCkpvaG4N Cg0K From nobody Tue Dec 1 06:55:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA79F1A92F6 for ; Tue, 1 Dec 2015 06:55:34 -0800 (PST) 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 LuU5En3strJo for ; Tue, 1 Dec 2015 06:55:26 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7D71A92F0 for ; Tue, 1 Dec 2015 06:55:26 -0800 (PST) Received: by wmec201 with SMTP id c201so17099179wme.1 for ; Tue, 01 Dec 2015 06:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=kFE6yA+l0EqJCuJ7rFY1W7lmVLCjAOrc9ZahTenpNO0=; b=NDG/BtcqOJcknQbEWnzDIiTCqP8gPlvnl10fWy+bDeInl28wG/cNH24FhOJ4m7Vhi1 H+EjvpAX3EgJiodsYnzc9nXAU4oYRK2rGeQkPADj4s6tUd93tukCnraWaPnKnmwDpOpk dXmHYCLzk8GziqhZnAMwyMX3Jm6FrPhMgXlPoa1nh6doINHmRR1Fyol9/ay6ZbbnlRyF yR0SLBdnr+RP7esrBiu9oPgYlov+5YBh9St+zbthPhZouGxXkBeyVCOJIJ8OEhX2AgLS opf3HZ/JxGHW77R+cCjZQ6UP36+e3mQ+6FWl41t/is6IjRTAI/tkNDxaoazhTWWJ88wN G3sw== X-Received: by 10.28.72.137 with SMTP id v131mr37709513wma.63.1448981724644; Tue, 01 Dec 2015 06:55:24 -0800 (PST) Received: from tsf-476-wpa-4-097.epfl.ch (tsf-476-wpa-4-097.epfl.ch. [128.179.180.97]) by smtp.gmail.com with ESMTPSA id m16sm26682034wmb.13.2015.12.01.06.55.23 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Dec 2015 06:55:23 -0800 (PST) To: tls@ietf.org References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <3B906BDF-CA30-4EDF-ADA9-ABFC2A25014D@gmail.com> From: Bryan A Ford X-Enigmail-Draft-Status: N1110 Message-ID: <565DB4D9.309@gmail.com> Date: Tue, 1 Dec 2015 15:55:21 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <3B906BDF-CA30-4EDF-ADA9-ABFC2A25014D@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020600020804000806060701" Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 14:55:34 -0000 This is a cryptographically signed message in MIME format. --------------ms020600020804000806060701 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/1/15 10:12 AM, Yoav Nir wrote: >> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum wrote= : >> On 12/1/15, Viktor Dukhovni wrote: >>> * Interoperable in the field with various capital-intensive >>> middle boxen. >> >> Which would those be? And what is the definition of capital-intensive >> for those watching on the sidelines? >=20 > Firewall, IPS/IDS devices. Boxes that attempt to perform sanity-check o= n protocols to make sure that the stuff going over TCP port 443 is really= HTTPS rather than an attempt at tunneling. There are some attacks such t= he the code that protects against them needs to follow TLS record sizes. = For the most part these are not-so-interesting attacks, causing certain v= ersions of certain browsers to hang, and they are expensive for the firew= all to protect against, so for the most part these protections are turned= off. But it=E2=80=99s not everywhere. Certainly there are middleboxes that try to use traffic analysis to detect attempts at tunneling - but the fact that the traffic is HTTPS doesn't mean there's no tunneling; in fact the HTTPS CONNECT operation does exactly that (and is sometimes used for exactly that purpose). Regardless, does the IETF really want to be in the business of making sure that protocols like TLS are designed to avoid making life inconvenient for developers of Great Firewalls of whatever type? > If enough middleboxes block TLS 1.3, the browsers will implement a down= grade dance. If they do that, attackers will be able to exploit the downg= rade dance. I don=E2=80=99t think the net effect is better security. We=E2= =80=99d be far better off writing a separate document on how to use the p= adding feature that is already in 1.3 to mitigate traffic analysis withou= t actually flooding your Internet connection. Splitting records and paddi= ng a few can be more effective than masking the length bits. Browsers have to implement a downgrade dance anyway to be able to talk with web servers that don't support TLS 1.3. TLS 1.3 already changes plenty of things that middleboxes "might" not like; absent concrete evidence of major incompatibilities specifically caused by the proposed change, I don't see why we should avoid changing one more bit of the protocol that middlebrowsers "might" not like. B --------------ms020600020804000806060701 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwMTE0NTUyMVowLwYJKoZIhvcNAQkEMSIEIFDbfKpHrxIhEZihUpmZ64ZcabsSuENoADwS 0qSjC5vcMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBAAAbdgV6SC6KwAJq 1zmTVsA8R/uUQH5n4V6CEINIwuAR+TyAK/RxEm7kkuoP0O85imk084Kw1SH296xiI81tXPlc 5B66PDQnEGFJr8v4mOWYQKkZasPZezdLiMViyp91zjGANB1XPMzwFST6JBXgyJ/tE0ooah+o zCxe0AhEZBp86xF4DYk8hNBEtiL4tfkTDXrf616iDEtVBFevCSpxlx5o6NR/JdVcpPVz44xL AMlnSNqRJm6huLqooMsWmV4Lpha4f/9b/02RG8i5b36zii3vUwa5c4oOrw4xZ6tBLNPYnSmt Ny6IDxefRbNeH5C+7voIEydqUsAvm++mZiwmDH0AAAAAAAA= --------------ms020600020804000806060701-- From nobody Tue Dec 1 07:27:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EE11AC444 for ; Tue, 1 Dec 2015 07:27:39 -0800 (PST) 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 HH1sQzg_0VOv for ; Tue, 1 Dec 2015 07:27:37 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1DCE1AC442 for ; Tue, 1 Dec 2015 07:27:36 -0800 (PST) Received: by wmvv187 with SMTP id v187so212229095wmv.1 for ; Tue, 01 Dec 2015 07:27:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=q78zUr0/Mjm/tQ3/E9wm18sCarLKwKfA6ITVDtve0nU=; b=YQcqBxsc0+Dy8IJSwA5GdXleyszuQJy2rYaHW+Y7wuOW4mZj7HWVJ+Ukqt/H4Z7jSj 0YsA8VB7O6rexGcO9PNnZ89CgxX40nfgBE9CG9aoEjqQ90NDM+3Zcqiae5EEozRIdGCj pfMQ6GKBaLAqEH5Py+bGkmZF7G8QS1ko+iYImnAWA4baRGB81ypqjurUqWPoghFPInQ4 IJ3SHymUsGViY5qSIBP5cXmWtzaTrHVMiwq0fNK21SifMCXIU+i5rqGbxjXukVkBVhKs Fm3Qof9ifGsnrizumkiJf8gQQ4J2wR7qJwqFom1OJdkoYElZxL7EmWfUeqFCV980tcz2 ZvaA== X-Received: by 10.194.236.6 with SMTP id uq6mr58397862wjc.126.1448983655322; Tue, 01 Dec 2015 07:27:35 -0800 (PST) Received: from tsf-476-wpa-4-097.epfl.ch (tsf-476-wpa-4-097.epfl.ch. [128.179.180.97]) by smtp.gmail.com with ESMTPSA id b84sm26626852wmh.15.2015.12.01.07.27.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Dec 2015 07:27:33 -0800 (PST) To: Fabrice Gautier References: <56586A2F.1070703@gmail.com> From: Bryan A Ford X-Enigmail-Draft-Status: N1110 Message-ID: <565DBC63.5090908@gmail.com> Date: Tue, 1 Dec 2015 16:27:31 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020207040308070106040506" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 15:27:39 -0000 This is a cryptographically signed message in MIME format. --------------ms020207040308070106040506 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/1/15 4:02 AM, Fabrice Gautier wrote: > 1) What would be the implications of this for DTLS? (Knowing that one d= ifference between TLS and DTLS is the record header) Good question. Fortunately my proposal should be fairly easy to adapt to DTLS, with one small trick. The main issue is that DTLS packets need to contain explicitly transmitted sequence numbers rather than implicit sequence numbers, because packets can be received out of the order and the receiver needs to know which sequence number (and hence which nonce) to use to try to decrypt and integrity-check. But if we encrypt the full DTLS header including sequence number, how does the receiver decrypt it without knowing the correct nonce to use to decrypt it? An apparent chicken-and-egg problem. Fortunately the solution is fairly simple: the receiver simply pre-computes and keeps in a small hash table the encrypted sequence numbers of all packets with sequence numbers between H-W and H+W, where H is the highest sequence number correctly received so far (the horizon) and W is the anti-replay window size as specified in 4.1.2.5 of RFC 4347, which typically should be 32 or 64 according to the RFC. The receiver can precompute all these encryptions because in my proposal TLS headers are encrypted with a stream cipher (or the AEAD operating as a stream cipher), so it's just a matter of producing the correct cipherstream bytes and XORing them with the uint48 sequence number. Whenever the receiver gets a datagram, it looks up the encrypted sequence number in the hash table, drops it on the floor if it's not present, and if it's present the receiver gets the decrypted sequence number from the hash table and uses that in the AEAD decryption and integrity-check. In the low-probability event of a hash-table collision (i.e., two uint48 sequence numbers encrypting to the same 48-bit ciphertext in a single 129-datagram window), the receiver can trial-decrypt with both (or all) sequence numbers in that colliding hash table entry. Or the receiver can keep it even simpler and just drop all but one colliding entry, introducing a pretty low probability of introducing occasional "false packet drops." The hash table is pretty trivial to maintain efficiently as well: e.g., whenever the horizon H moves forward by delta D, remove the first D entries from the current window and precompute another D encrypted sequence numbers (where D will most often be 1). In the simple design that doesn't bother dealing with hash table collisions (e.g., that allows each hash table entry to contain only one value), perhaps don't even bother clearing/removing old entries; just gradually overwrite them with new ones as H moves forward. > 2) In some implementations the record framing/parsing and encryption/de= cryption are down at different layers. Would this proposal make this type= of implementation impossible?=20 Not that I'm aware of, but I might need more information about the specific layering approaches you're thinking of and how "strongly enforced" that layering might be. But in the version of my proposal that operates the "normal" AEAD as a stream cipher for header encryption/decryption purposes, it doesn't seem like any change would be needed to the standard AEAD encryption/decryption interface. It should even be fine if the AEAD was implemented as a separate hardware module that takes the standard AEAD interface inputs and produces the standard AEAD outputs; as long as it supports the standard AEAD API it should be perfectly usable in the design I proposed. The one potential issue I can think of if a particular, restricted API forces the caller to commit at key-setup time to either "AEAD encryption mode" or "AEAD decryption mode", and makes it difficult or impossible to switch back and forth. In that case in my proposal as it stands the receiver TLS implementation might need to set up and maintain two hardware contexts, one for AEAD decryption (for the payloads), the other for AEAD encryption (for stream cipher header decryption), both using the symmetric key. This still doesn't seem all that problematic to me, though, and I don't even know of any particular APIs offhand that present this particular issue. Cheers Bryan --------------ms020207040308070106040506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwMTE1MjczMVowLwYJKoZIhvcNAQkEMSIEIE4s41HPA3EkSNGXKWM3JFdO3dxwRsHwLY3A snOlnJ/tMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBAGNr/pu6+3tTgAnI iUXkJni5ywE3IK5m56F3aOu0FUXywg7yJbyPrlb2AZg2FPIG1NBnUCfhiCxPQcrlqmTwPkSZ C+hYDv5ZCX3IIq3BGMxd05+RV1bba7OFmuLnOatC2Z8Iz+pafcGwQH/4WNIf/nBXUp9/CZrv 2AQ78x4i9uDlJOGKIUtG5/bievBjFSgEk5kiwHVc+hA+wCNffN6uvI/A8/8XwL8BqIa6Y3f5 PqA2a4EmWLPhkIR+4WXChbAlC/6DXsLa4/rJpoutQGpzuYS2qchqHgSPD8xPguws2X6I2iS8 DMTPInI/2sWY4YdVEywawiKXnneCUCXS/golpCUAAAAAAAA= --------------ms020207040308070106040506-- From nobody Tue Dec 1 08:22:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39161ACDE7 for ; Tue, 1 Dec 2015 08:22:20 -0800 (PST) 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 JGg-vxM75rQT for ; Tue, 1 Dec 2015 08:22:18 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4CD51ACDA2 for ; Tue, 1 Dec 2015 08:22:17 -0800 (PST) Received: by wmww144 with SMTP id w144so20353910wmw.0 for ; Tue, 01 Dec 2015 08:22:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=aeULmDYm6Dfy69tG8HTKrIpb4oTpOYY49InzjcG7tKE=; b=iWbclNxc7KLx4o8RNmDmI/z2DCWM/Ewm5d3Cx2bDRhE5VLsqSpnLJ+AyU7ReXXIRT3 8DU2/C9rhrdcMl9yiWWe72CF7qvzv8/EJMkoIbW72RIW6LACyvxMUfKoIQyhL6sYevlM P/Jg8NLmVNakWkwH8QISgy8TaGxl1jF2DY4npSWxAnfiMmMi68GWdeWjPN1Uq87NqMm6 DZdRXHncVkGMNT3tEeDCxU2f9Dwcirht7cdLgrhBqHgUQvSyH7pCU+L5U29LV9yqfvro PX0nFy8Bautv2o/7/HcvvHX0qTxutLJ1skndLHPgpZQ1ryzAfW2Qa8Vr80Dqfh7avEhf kt+g== X-Received: by 10.28.68.133 with SMTP id r127mr37617099wma.71.1448986936052; Tue, 01 Dec 2015 08:22:16 -0800 (PST) Received: from tsf-476-wpa-4-097.epfl.ch (tsf-476-wpa-4-097.epfl.ch. [128.179.180.97]) by smtp.gmail.com with ESMTPSA id z13sm51675566wjr.47.2015.12.01.08.22.14 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Dec 2015 08:22:14 -0800 (PST) References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> To: "tls@ietf.org" From: Bryan A Ford X-Enigmail-Draft-Status: N1110 Message-ID: <565DC935.2040607@gmail.com> Date: Tue, 1 Dec 2015 17:22:13 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565DBC63.5090908@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070405090005090706030703" Archived-At: Subject: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 16:22:21 -0000 This is a cryptographically signed message in MIME format. --------------ms070405090005090706030703 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Some of the parallel discussion on the SSH list - especially comments by Simon Tatham and Niels M=F6ller - made me think of an alternative design that would not only hide TLS headers but also ensure that they are integrity-checked by the receiver *before* the receiver attempts to interpret the record header in any way. This alternative approach already feels to me like an improvement over my last one, and perhaps even those who are skeptical of the need to encrypt TLS headers might appreciate the desirability of closing vulnerabilities to length-fiddling attacks: e.g., where an attacker sets the high bit of the length field in the last TLS record so that the receiver will likely hang on a long read before detecting the change. Proposal: The basic idea is in some respects even simpler than the last one: 1. We move the TLS header from the "additional data" field to the start of the "plaintext" field. That is, the sender encrypts the header along with the payload, and the receiver decrypts and integrity-checks the header along with the payload, using the standard AEAD interface. The "additional data" field now contains *only* the sequence number, which both sender and receiver track and compute implicitly. 2. The 2-byte length field in each record's header no longer indicates the length of the *current* record but instead indicates the length of the *next* record. The length of the first record might be defined in a new field we add to the handshake/key-exchange protocol, or it might simply be set to some well-known standard first record size. That's basically it. The key advantage is that this way the receiver always "knows" the correct size of each record before having to read or interpret any part of it in any way. In fact, because the record is fully encrypted, the receiver implementation is basically forced to use the AEAD to decrypt and integrity-check the record before doing anything at all with it, which closes down not only the well-known length-fiddling attack that has dogged SSH, but a whole class of possible potential implementation bugs regarding the (delicate) handling of cleartext TLS headers before they've been integrity-checked. Basically, this ensures that if the receiver have any bugs in the handling of the TLS header, they can be exploited only by its communication partner, and not by an attacker in the middle of the path. To me this seems like a useful robustness benefit completely independent of the (also desirable) benefits with respect to traffic analysis. Choosing next-record lengths: Of course this approach presents the minor challenge that the sender must always "commit" to the length of the next record before sending the current one. But this challenge is pretty easy to deal with. The easiest way to handle it, of course, is if the sender simply pads all packets to the same record length - a solution I would generally be quite happy with due to its complementary traffic analysis resistance benefits, and I would even favor explicitly encouraging that solution in the TLS RFC. I would love it if the next TLS RFC ended up containing a clause of the form: The TLS sender SHOULD always transmit TLS records of length exactly X, unless this is deemed impractical due to overriding performance or bandwidth-efficiency considerations. =2E..where "X" is some reasonable value we discuss and decide on. But my (new) proposal does not require all TLS implementations to maintain a fixed record size. If the sender implementation wants to use variable-size records, it can still process batches of records written together normally up until the last record in the batch. But when processing the last record in a write - or in general the last record before "going idle" where it does not yet have a next record to send - the sender simply "picks something." That something might for example be a minimum record size, meaning the next record will be big enough to hold a "next record length" indicating a useful length, but will otherwise be basically a no-op record, so we'll pay the cost of an extra small record and AEAD encryption/decryption each time transmission resumes after being idle. Alternatively the sender of variable-length records might pick a "typical record size" as the next-record-size to transmit in the last record in a burst; that way once transmission resumes the next record can probably carry useful data, but might need padding if its committed size is larger than the amount of data to be transmitted. The (important) existence of the padding mechanism already added in TLS 1.3 makes this alternative possible. DTLS: Now there's still the important question of whether this (new) proposal could be made to work in the context of DTLS. For the DTLS case, my current thinking is that some elements of my earlier proposal is probably more suitable: namely using a stream cipher (or AEAD used as a stream cipher) to encrypt and recognize the explicitly-transmitted sequence numbers that DTLS needs. This could operate basically the same as I described in my earlier E-mail on this topic. Note that the length field is no longer a problem in DTLS as it is in TLS, because the receiver already gets the length of the datagram from UDP. Comments/discussion? Is the above more (or less) palatable than my previous proposal? Cheers Bryan --------------ms070405090005090706030703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwMTE2MjIxM1owLwYJKoZIhvcNAQkEMSIEIFUp7roZ2OX8roddAsoGYnWUlfz8if+F9DYd 6pO275GzMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBAAwcI1jMq2N26Cvg vi5kaJ4uiFe1l/fKhWzNnzS+HeBmuF/LxtvyUTIWGdDOwiRTceSshOpVh1XK7pUAd7Kwq1Q5 v2Nc5E6SAgZ0TKzCtb5JMaQeuuUacaseJ98KJ3aZ91qeHMQWfbiBTwtASfDbydXA8ba5kp2i rgfiFu/8CvWqjwMxVKXVuOZT/7234lTfBYPfJaqEUBzlRlqIBjdN1VVtp66g6TLBTgEfoMON N96GD90abO/0LyYNeAI1yxyzcFMWXXN7e+Xtw4/UeNWCYh6lzkGYTvwuySx5oRMenDg5L3Gn fiLf+YW8DiH5o9EfmrgKtvoxE3PaSK97rYPu9lwAAAAAAAA= --------------ms070405090005090706030703-- From nobody Tue Dec 1 10:11:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2701B2E3A for ; Tue, 1 Dec 2015 10:11:24 -0800 (PST) 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 QnYuNSjPlIwi for ; Tue, 1 Dec 2015 10:11:22 -0800 (PST) Received: from filtteri2.pp.htv.fi (filtteri2.pp.htv.fi [213.243.153.185]) by ietfa.amsl.com (Postfix) with ESMTP id 451C41B2E5C for ; Tue, 1 Dec 2015 10:11:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri2.pp.htv.fi (Postfix) with ESMTP id C69CE19BE6E; Tue, 1 Dec 2015 20:11:20 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri2.pp.htv.fi [213.243.153.185]) (amavisd-new, port 10024) with ESMTP id nXt+cDb4VwFT; Tue, 1 Dec 2015 20:11:20 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id 96C805BC007; Tue, 1 Dec 2015 20:11:20 +0200 (EET) Date: Tue, 1 Dec 2015 20:11:18 +0200 From: Ilari Liusvaara To: Bill Cox Message-ID: <20151201181118.GA15222@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Dumb thoughts for hardware backed keys for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 18:11:24 -0000 On Mon, Nov 30, 2015 at 06:07:19PM -0800, Bill Cox wrote: > I don't think even I agree with this idea, but I'll put it out there anyway. > > We're seeing some new secure computing modes in ARM and Intel processors. > Arm has TEE, and Intel has SGX. Both modes basically run at the same speed > as the CPU... in theory. > > There are potential benefits to securing the read/write session keys in > these modes. For example, if malware is doing evil things over your > connections, when you remove the malware or close your laptop, the > encryption keys are out of reach, and the connections go dead. Otherwise, > malware might export the keys where they could be used to resume a session, > for example, enabling an attacker to continue doing evil. This is possible > today over TLS 1.2, even when using Client Certificates. > > However, there are overhead costs for moving data in/out of these execution > zones, and overhead when switching back and forth. Execution speed is a > little slower in these modes for various reasons. For maximum speed, I > might want a separate HMAC/HKDF key besides the read/write keys. That way, > I keep just the HMAC/HKDF key in a secure execution zone, and only have to > do one small operation with it per AEAD call per TLS record. > > This is just a dumb efficiency hack. I hate leaving either speed or > security on the table if I can have both :) However, complexity harms > security, so even I don't really think this is a good idea. Is there > anyone who feels even more strongly about speed than me? If you want absolute maximum speed without handling encryption in the secure module, you would essentially need the secure module to MAC the data second time (one can repurpose any AEAD ciphers as a MAC). (Hmm... why does this remind me of "key escrow"?... :-) ) The reason for this is that even the fastest hash-based MAC that is even remotely secure (Blake2b native MAC) loses in speed to both main TLS 1.3 AEADs (doing full authenticated encryption). You can't shorten things either, because the MACs in main TLS 1.3 AEADs are not designed to offer any security against attacker knowing the keys. And as said, schemes that allow shortening are relatively slow. -Ilari From nobody Tue Dec 1 10:12:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1523E1B2E5F for ; Tue, 1 Dec 2015 10:11:59 -0800 (PST) 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, HTML_MESSAGE=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 wbBUks-NC2_F for ; Tue, 1 Dec 2015 10:11:57 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4841B2E6B for ; Tue, 1 Dec 2015 10:11:57 -0800 (PST) Received: by ykdr82 with SMTP id r82so17166125ykd.3 for ; Tue, 01 Dec 2015 10:11:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type; bh=bs7GyNCQSXsjGUDWK5gBzALRXjd+sjSSMfZWBy7E0oU=; b=ecz3e1Fk3yywywW3xvI0wxOiYYC6eVhlgY84K1Im2ko1CLJJ3zrsj+LhhAWN2DiRe/ N36tsPxRsbuGjsPSipNdD61oXwZBNY1GxCg9/jE18G3mILsH0Ne6RsGhkxPe3STM9Vo0 iv94oI+wXDtFQT5fzOEnwkqzK4U/v9TuTwMVJ5A65nNGjzAz008WTc3T/s3Yb3bJD9aK p3XVBsB+PJjF0vYnQmIYdh56+Zrq+BUy3AFgyo4JLcCiMHPAtbBLxYhqPA+g7J5Kw2Kv c/mj/Pf03UOZA1ThX5rN5jo8YS5+h0I1wrkiCysjZXcyK709oxgmR7/e2j6js3jJoW/Y BgVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=bs7GyNCQSXsjGUDWK5gBzALRXjd+sjSSMfZWBy7E0oU=; b=Bzdpxiw42tBVSFWsTLCz997OpB2nEk2/O1X6h6nupoQN45q0DfMNM+J1MsArvR/Xeu 8pQhxYeKaX3kiV4FFmOyQL5eCZk9U1he28JZTXpPsmwRheSOU1yNH5BMkUbpR3LS/CWP xFuuazibDNJLt95XHUeUsQYUSeV5D+NzgoUHrifBbGobF0zsN3ysvt9f7p8P7BcLgU9r 7dB/Zh/c7gH83mEMlVKI+iV5XqrGlRWgHfy6+saUZEsZmYQkp8JYyiC4315p5p3pywKE Cx85PQyGSskqMgMCXV7hEGsc0e3dditMrrwuIeGVrVrLF0M15Dp3sww74Ly68QrY5Cy8 WPNQ== X-Gm-Message-State: ALoCoQlf1G5lb8EBarQCYFNxGEW34Pl6iQcwSK2urDe46JFJGpBn4M3red5/HYX0CTwaOZhpFk1x X-Received: by 10.13.236.10 with SMTP id v10mr67877278ywe.231.1448993516899; Tue, 01 Dec 2015 10:11:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 1 Dec 2015 10:11:17 -0800 (PST) From: Eric Rescorla Date: Tue, 1 Dec 2015 10:11:17 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0889dcdb80d50525da177e Archived-At: Subject: [TLS] Draft status and updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 18:11:59 -0000 --94eb2c0889dcdb80d50525da177e Content-Type: text/plain; charset=UTF-8 Hi folks, I've merged a bunch of PRs into the editor's draft, including: - https://github.com/tlswg/tls13-spec/pull/316 The new structure for client auth and post-handshake client auth we discussed in Yokohama. - https://github.com/tlswg/tls13-spec/pull/342 Using the "normal" content types for 0-RTT data and close_notify to indicate the end of the 0-RTT application data. - https://github.com/tlswg/tls13-spec/pull/352 - https://github.com/tlswg/tls13-spec/pull/317 Use SHA-1 to control what we sign with. - https://github.com/tlswg/tls13-spec/pull/284 The anti-downgrade mechanism that Karthik proposed - https://github.com/tlswg/tls13-spec/pull/345 Updating the IANA considerations per the discussion in Yokohama. This clears out the big pipeline stall from PR#316, but probably has created some bustage. Expect a series of cleanup commits and some other things that were head-of-line blocked this week and then draft-11 in the next week or so. Please file PRs and/or github issues for any issues you see. In addition, PR#354 (https://github.com/tlswg/tls13-spec/pull/354) implements the rekey mechanism that we discussed in Yokohama. There was broad agreement to adopt something like this. I would appreciate it if a few people could give it a sanity check, but absent strong objections, I intend to merge this PR on Friday. We also need to discuss three more substantive technical issues: - Encrypted SNI. - Whether the 0-RTT handshake messages are hashed into the handshake hash. - Statelessness for HelloRetryRequest, and in particular cookie lifetime. I'll be starting threads on those over the next few days with the aim of resolving them promptly. -Ekr --94eb2c0889dcdb80d50525da177e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi folks,

I&#= 39;ve merged a bunch of PRs into the editor's draft, including:

=C2=A0 The new= structure for client auth and post-handshake client
=C2=A0 auth = we discussed in Yokohama. =C2=A0 =C2=A0 =C2=A0
=C2=A0=C2=A0
=
=C2=A0 Using the "norm= al" content types for 0-RTT data and close_notify
=C2=A0 to = indicate the end of the 0-RTT application data.

- https://github.com/tlswg/tls13-spec/pull/317
=C2=A0 Use SHA-1 to control what we sign with.

=C2=A0 The anti-downgrade = mechanism that Karthik proposed

=C2=A0 Updating the IANA considerations per the di= scussion in Yokohama.


This clears o= ut the big pipeline stall from PR#316, but probably has
created s= ome bustage. Expect a series of cleanup commits and some
other th= ings that were head-of-line blocked this week and then
draft-11 i= n the next week or so. Please file PRs and/or github
issues for a= ny issues you see.

implements the rekey mechanism that we disc= ussed in Yokohama.=C2=A0 There
was broad agreement to adopt somet= hing like this.=C2=A0 I would appreciate
it if a few people could= give it a sanity check, but absent strong
objections, I intend t= o merge this PR on Friday.


We also = need to discuss three more substantive technical issues:

- Encrypted SNI.
- Whether the 0-RTT handshake messages ar= e hashed into the
=C2=A0 handshake hash.
- Statelessnes= s for HelloRetryRequest, and in particular cookie
=C2=A0 lifetime= .

I'll be starting threads on those over the n= ext few days with
the aim of resolving them promptly.
<= br>
-Ekr



= =C2=A0=C2=A0
=C2=A0=C2=A0








--94eb2c0889dcdb80d50525da177e-- From nobody Tue Dec 1 10:57:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24401B2C47 for ; Tue, 1 Dec 2015 10:57:39 -0800 (PST) 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 zviBgMcL6dLC for ; Tue, 1 Dec 2015 10:57:37 -0800 (PST) Received: from filtteri6.pp.htv.fi (filtteri6.pp.htv.fi [213.243.153.189]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6641B2F17 for ; Tue, 1 Dec 2015 10:57:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri6.pp.htv.fi (Postfix) with ESMTP id E2DB256F881; Tue, 1 Dec 2015 20:57:35 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri6.pp.htv.fi [213.243.153.189]) (amavisd-new, port 10024) with ESMTP id xiuoP+yyUB3u; Tue, 1 Dec 2015 20:57:35 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id 9DAD15BC00A; Tue, 1 Dec 2015 20:57:35 +0200 (EET) Date: Tue, 1 Dec 2015 20:57:34 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20151201185733.GB15222@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft status and updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 18:57:40 -0000 On Tue, Dec 01, 2015 at 10:11:17AM -0800, Eric Rescorla wrote: > > This clears out the big pipeline stall from PR#316, but probably has > created some bustage. Expect a series of cleanup commits and some > other things that were head-of-line blocked this week and then > draft-11 in the next week or so. Please file PRs and/or github > issues for any issues you see. Looks like the note about the PSK+ClientCert "attack" got lost somewhere. While I don't think that is important as the underlying issue is fixed, I think there might be a note about dangers of using server certificates in any mode where transcript and configuration do not jointly imply SS. Actually, scanning the editor's copy, it looks VERY broken to me: I don't see how server certificate verify (indirectly) signs on the old configuration. Such signing is required for security, as otherwise SS is not impiled by signature, breaking authentication. Previously, the document was clear about this... > In addition, PR#354 (https://github.com/tlswg/tls13-spec/pull/354) > implements the rekey mechanism that we discussed in Yokohama. There > was broad agreement to adopt something like this. I would appreciate > it if a few people could give it a sanity check, but absent strong > objections, I intend to merge this PR on Friday. The restrictions on when the rekey message can be sent: Do those essentially boil down to "any time after sending Finished"? Also, I think the requirement to immediately send the KeyUpdate is problematic. I think it should be requirement to send it as next record(s). The two aren't the same: The first seemingly requires scheduling extra flights, which can be problematic. The second can piggyback on existing flights. -Ilari From nobody Tue Dec 1 11:20:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6481B2F2B for ; Tue, 1 Dec 2015 11:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] 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 uk4hEe6fy7qR for ; Tue, 1 Dec 2015 11:19:56 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63091A1A36 for ; Tue, 1 Dec 2015 11:19:55 -0800 (PST) Received: by ykfs79 with SMTP id s79so19811536ykf.1 for ; Tue, 01 Dec 2015 11:19:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8ryXnBnehapHYDZkVedxVmeohw5fI5okpjVNKGfZGrQ=; b=nOvq5jAcFaKz4Ngns2V9qucA3yj4HWRmsV9I3uAX+tSkKeT1PgCLjypvoKeOyKc/7M APFDRelKr0KeMKL69Nm77dPyTb6xL/e8ndj/THlwX9q7aH6pB+Pg8Qh3RDYPoNpiWISd H/COfckv/AY46vF2avYshaipG7oaCt+KtaEgEe4GThc+ch3X4LiLZ0XOzv967XhU5SZk 7ZM7AXzwY2wYc4d1LkyNzei3wiCHay+ShHkFQQ8n4496j6IhUB6odxuyOTQDp6ZKOCaZ FDb0ve5GjAAxxAkjufxkY6GCjMYw8GFifFshr4s0/g1OeU+cP3jCt9rkvVOO6VHxlXmM bQQg== 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=8ryXnBnehapHYDZkVedxVmeohw5fI5okpjVNKGfZGrQ=; b=VUjC1WqQ17B2SmCclacPYHGbBWE4hhdGrr4fIzh9oVaDJT92gFzIpuRojfWFaD0ONZ B4ReH56qDmxXxye3weMxsOLOwhWOOy8Rfd9rLDzrCUw0DefT6HA02tvnrHaLyxlpyzAX 5lJjCmMaE1GnEScs4CZLZ3wVzftfodaC7eHT0aHbIH3bhNPylCZ7fKtww4wHGu8RFypD dNVMzwYHDshvCBQhu9MBmScZTf1UL0pckcT5OADvK4ZzQkk/llSy7ICGrIdguXFT/KZn dQ+QeM5P0zBFx02O2yHnL4AtUnAhxawh0eteng/itTbtEJtMzOlMGT4v2vTMKCPXNTIe I1uQ== X-Gm-Message-State: ALoCoQlTthrWf1gBhnwIL/i8k2HRhA2oAQHw+6YMqSFn2HL6JN1YgR+EfXpCBPOczn6hKwkXQNHT X-Received: by 10.13.212.211 with SMTP id w202mr32687611ywd.192.1448997595076; Tue, 01 Dec 2015 11:19:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 1 Dec 2015 11:19:15 -0800 (PST) In-Reply-To: <20151201185733.GB15222@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151201185733.GB15222@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Tue, 1 Dec 2015 11:19:15 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114fbe98ef90a80525db0ae7 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft status and updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 19:19:58 -0000 --001a114fbe98ef90a80525db0ae7 Content-Type: text/plain; charset=UTF-8 Ilari, Thanks for your quick review. On Tue, Dec 1, 2015 at 10:57 AM, Ilari Liusvaara wrote: > On Tue, Dec 01, 2015 at 10:11:17AM -0800, Eric Rescorla wrote: > > > > This clears out the big pipeline stall from PR#316, but probably has > > created some bustage. Expect a series of cleanup commits and some > > other things that were head-of-line blocked this week and then > > draft-11 in the next week or so. Please file PRs and/or github > > issues for any issues you see. > > Looks like the note about the PSK+ClientCert "attack" got lost > somewhere. See the last graf of: http://tlswg.github.io/tls13-spec/#certificate-verify I pointed to the e-mail by Sam's group and also prohibit entirely the use of cert-based client auth in pure PSK, since that seemed safer. If you think more is needed here I would be happy to add it. While I don't think that is important as the underlying > issue is fixed, I think there might be a note about dangers of using > server certificates in any mode where transcript and configuration > do not jointly imply SS. > > Actually, scanning the editor's copy, it looks VERY broken to me: > I don't see how server certificate verify (indirectly) signs on the old > configuration. Such signing is required for security, as otherwise > SS is not impiled by signature, breaking authentication. > > Previously, the document was clear about this... > I'm sorry, but I'm not following the issue you are raising here. Perhaps you could expand further? Here's my reasoning. 1. The server delivers the server configuration in handshake #0 and signs the entire transcript with the certificate verify. At this point the client has assurance of the server's g^s. 2. In handshake #1, the client sends g^x and there is authentication for g^xs and hence the client knows that any data it is sending to the server in 0-RTT is actually going to the server. 3. The server provides g^y in his ServerHello and then g^xy and g^xs are jointly used to produce the traffic keys and also to form a MAC over the handshake. As Hugo pointed out originally, this alone should be sufficient to authenticate the server's side of the connection and you could omit the server CertificateVerify (Hugo, please correct me if I have misunderstood). 4. However, for consistency reasons (per the discussion in Prague), the server *also* signs the entire transcript. This authenticates g^y (even though the MAC with g^xs already authenticated it) and proves possession of the signing key. Trying to read between the lines, is your concern that the server is now no longer explicitly signing over the ServerConfiguration in its CertificateVerify [Note that the client continues to do so]? The idea behind removing that was to make the 1-RTT part of the handshake more uniform regardless of whether 0-RTT data was used. I'm certainly open to putting that back in if it's needed, but can you explain your concern in more detail? > In addition, PR#354 (https://github.com/tlswg/tls13-spec/pull/354) > > implements the rekey mechanism that we discussed in Yokohama. There > > was broad agreement to adopt something like this. I would appreciate > > it if a few people could give it a sanity check, but absent strong > > objections, I intend to merge this PR on Friday. > > The restrictions on when the rekey message can be sent: Do those > essentially boil down to "any time after sending Finished"? > Except not during 0-RTT. Also, I think the requirement to immediately send the KeyUpdate > is problematic. I think it should be requirement to send it as > next record(s). > The two aren't the same: The first seemingly requires scheduling > extra flights, which can be problematic. The second can piggyback > on existing flights. > Good suggestion. PR welcome. :) -Ekr > > > -Ilari > --001a114fbe98ef90a80525db0ae7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ilari,

Thanks for your quick review.

On Tue, Dec 1, 2= 015 at 10:57 AM, Ilari Liusvaara <ilariliusvaara@welho.com><= /span> wrote:
On Tue, Dec 01, 2015 at = 10:11:17AM -0800, Eric Rescorla wrote:
>
> This clears out the big pipeline stall from PR#316, but probably has > created some bustage. Expect a series of cleanup commits and some
> other things that were head-of-line blocked this week and then
> draft-11 in the next week or so. Please file PRs and/or github
> issues for any issues you see.

Looks like the note about the PSK+ClientCert "attack" got = lost
somewhere.
=C2=A0
See the last graf of:
http://= tlswg.github.io/tls13-spec/#certificate-verify
=C2=A0
I pointed to the e-mail by Sam's group and also prohibit entirel= y
the use of cert-based client auth in pure PSK, since that
=
seemed safer. If you think more is needed here I would be happy
<= div>to add it.


While I= don't think that is important as the underlying
issue is fixed, I think there might be a note about dangers of using
server certificates in any mode where transcript and configuration
do not jointly imply SS.

=C2=A0
Actually, scanning the editor's copy, it looks VERY broken to me:
I don't see how server certificate verify (indirectly) signs on the old=
configuration. Such signing is required for security, as otherwise
SS is not impiled by signature, breaking authentication.

Previously, the document was clear about this...

<= /div>
I'm sorry, but I'm not following the issue you are raisin= g here. Perhaps
you could expand further? Here's my reaso= ning.

1. The server delivers the server configurat= ion in handshake #0
and signs the entire transcript with the cert= ificate verify. At this
point the client has assurance of the ser= ver's g^s.

2. In handshake #1, the client send= s g^x and there is authentication
for g^xs and hence the client k= nows that any data it is sending to the
server in 0-RTT is actual= ly going to the server.

3. The server provides g^y= in his ServerHello and then g^xy and g^xs
are jointly used to pr= oduce the traffic keys and also to form a MAC over
the handshake.= As Hugo pointed out originally, this alone should
be sufficient = to authenticate the server's side of the connection and
you c= ould omit the server CertificateVerify (Hugo, please correct
me i= f I have misunderstood).

4. However, for consisten= cy reasons (per the discussion in Prague),
the server *also* sign= s the entire transcript. This authenticates
g^y (even though the = MAC with g^xs already authenticated it)
and proves possession of = the signing key.

Trying to read between the lines,= is your concern that the server is
now no longer explicitly sign= ing over the ServerConfiguration in
its CertificateVerify [Note t= hat the client continues to do so]? The idea
behind removing that= was to make the 1-RTT part of the handshake
more uniform regardl= ess of whether 0-RTT data was used.=C2=A0
I'm certainly open = to putting that back in if it's needed, but can you
explain y= our concern in more detail?



> In addition, PR#354 (https://github.com/tlswg/tls13= -spec/pull/354)
> implements the rekey mechanism that we discussed in Yokohama.=C2=A0 Th= ere
> was broad agreement to adopt something like this.=C2=A0 I would apprec= iate
> it if a few people could give it a sanity check, but absent strong
> objections, I intend to merge this PR on Friday.

The restrictions on when the rekey message can be sent: Do those
essentially boil down to "any time after sending Finished"?

Except not during 0-RTT.=C2=A0

Also, I think the requirement to immediately send the KeyUpdate
is problematic. I think it should be requirement to send it as
next record(s).=C2=A0

The two aren't the same: The first seemingly requires scheduling
extra flights, which can be problematic. The second can piggyback
on existing flights.

Good suggestion. P= R welcome. =C2=A0:)

-Ekr




-Ilari

--001a114fbe98ef90a80525db0ae7-- From nobody Tue Dec 1 11:28:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D371B2F34 for ; Tue, 1 Dec 2015 11:28:51 -0800 (PST) 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_40=-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 5YLbzKqND6EP for ; Tue, 1 Dec 2015 11:28:50 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F38E91B2E4F for ; Tue, 1 Dec 2015 11:28:49 -0800 (PST) Received: by ykdr82 with SMTP id r82so19870361ykd.3 for ; Tue, 01 Dec 2015 11:28:49 -0800 (PST) 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=VKFmSmqDSbFXE6rD13bl8gYYgXnSttNgUGYPcE0DTkQ=; b=n7/5FvGnIEVXvdXtU9y3pZbIOv7c9XsIwJPSiwrRIYtdQ9dpVihOliRkL7xkFfXc2Q Fs0g5hQ36xX0nw65mjYFa6eei9TnpZSwugHEwDbFqoZlSbAwcYxZrDWyuaJs/VGwHT78 EgIQkKaRKXeeTqoz7G+XvfDqFyy1Vctio1Rlu/dnLXHlKPWOPzInMNMwFneUCS/c6zLg WTyaTWE/fompufoB0hEHCqr6uRjnyqVVwr/qfSu2uAg6S7UVEs2DLdLt0ZQ/YU8BBm5d uBb1oIwM+E5lY7XV+CSdKOla7v4JpePxVy7CeXKTs53aQhvogSplSfGOf6TrC8yrUYqU jNdA== MIME-Version: 1.0 X-Received: by 10.129.99.195 with SMTP id x186mr59908555ywb.345.1448998129320; Tue, 01 Dec 2015 11:28:49 -0800 (PST) Received: by 10.129.148.131 with HTTP; Tue, 1 Dec 2015 11:28:49 -0800 (PST) Date: Tue, 1 Dec 2015 14:28:49 -0500 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Fresh results X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 19:28:51 -0000 https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf This one looks very nasty to fix. Short of disallowing the use of RSA certificates for TLS 1.2 with the RSA handshake and in TLS 1.3, I don't see a good fix. I haven't read this paper in detail yet. Cross-protocol attacks are the gift that keeps giving. Sincerely, Watson From nobody Tue Dec 1 11:29:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61D71B2F5E for ; Tue, 1 Dec 2015 11:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] 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 RKymutp3u6zt for ; Tue, 1 Dec 2015 11:29:25 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADB271B2F5A for ; Tue, 1 Dec 2015 11:29:25 -0800 (PST) Received: by ykfs79 with SMTP id s79so20144190ykf.1 for ; Tue, 01 Dec 2015 11:29:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6IidVQfhdhafZjBME/nplCo7FiAzLjJqXDPKUTSdFME=; b=aIS+JwVo2OAJIMq7WuliqNvbl6yvWZwN5/PbL7Ua74NxjFsnj34Y1Pz+Ve1seRFyvX lWnjlBi2GcA0BDr7r2OW1IUkecFO7fzAXDWGbJE7097s+ABk0v1mbn5h1SKuat/MlJpX nNiNqOtLbCHyYn9K2QoTMf0O/LuQr7JCRoKTvUXgaiEXe8mS7gqCE6HwmeGwAckr+jZH tLpXJ5XCIP+7q+GZxLTQ1B4bTA1v3HSjOuBqz8hrHEJgkGOnOz5s1albM+jSplQhali9 9TnNiN7nbOBgKBCloRsJJOstoEyfwpGk5m80RhetMUVENsF+KSEBZK48ayM/S4URbMce 4iVw== 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=6IidVQfhdhafZjBME/nplCo7FiAzLjJqXDPKUTSdFME=; b=jSj/LbPvp4VCpRxOBCXZ+NisIjI07KUBZDjCViX7zhbO/dSPfoYTBWbeBloucCkgQe S/nEdY1TdoSf8+OS21clsOz/Xx8ZmOkIodeUvhCT8/chLaPi168H67K57ua7P2kOqvuJ P0g2IxQ2z9PLXXjCmu3qrBGD49Wt4ZQ/39d9fUYUjrKFe92sgdzNiGnDzezYXSTdaLH4 6bY9Ntysi54RqG06odtqcmZosRLekiUFm4V1Fly3/BZRrE7cUAftkc0bI8Qtm7b5ZICE 9mt+Ka6UI6QAY3epOHOTr2rMRxcuVDhKkgq4a4xh2coOSXyJMnnFnB43xaVY5X9jkEDi /GUg== X-Gm-Message-State: ALoCoQkfx2xM2JxwJzIoeCas7wj9h/d7n+P5rTfVUAR/kWqLvtHdAIYxTv/SdKLVtvDCwX3ZMwWY X-Received: by 10.129.73.198 with SMTP id w189mr30382985ywa.223.1448998164973; Tue, 01 Dec 2015 11:29:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 1 Dec 2015 11:28:45 -0800 (PST) In-Reply-To: References: <20151201185733.GB15222@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Tue, 1 Dec 2015 11:28:45 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114dc814e778ad0525db2c5d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft status and updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 19:29:28 -0000 --001a114dc814e778ad0525db2c5d Content-Type: text/plain; charset=UTF-8 On Tue, Dec 1, 2015 at 11:19 AM, Eric Rescorla wrote: > Ilari, > > Thanks for your quick review. > > On Tue, Dec 1, 2015 at 10:57 AM, Ilari Liusvaara > wrote: > >> On Tue, Dec 01, 2015 at 10:11:17AM -0800, Eric Rescorla wrote: >> > >> > This clears out the big pipeline stall from PR#316, but probably has >> > created some bustage. Expect a series of cleanup commits and some >> > other things that were head-of-line blocked this week and then >> > draft-11 in the next week or so. Please file PRs and/or github >> > issues for any issues you see. >> >> Looks like the note about the PSK+ClientCert "attack" got lost >> somewhere. > > > See the last graf of: > http://tlswg.github.io/tls13-spec/#certificate-verify > > I pointed to the e-mail by Sam's group and also prohibit entirely > the use of cert-based client auth in pure PSK, since that > seemed safer. If you think more is needed here I would be happy > to add it. > > > While I don't think that is important as the underlying >> issue is fixed, I think there might be a note about dangers of using >> server certificates in any mode where transcript and configuration >> do not jointly imply SS. >> > > > >> Actually, scanning the editor's copy, it looks VERY broken to me: >> I don't see how server certificate verify (indirectly) signs on the old >> configuration. Such signing is required for security, as otherwise >> SS is not impiled by signature, breaking authentication. >> >> Previously, the document was clear about this... >> > > I'm sorry, but I'm not following the issue you are raising here. Perhaps > you could expand further? Here's my reasoning. > > 1. The server delivers the server configuration in handshake #0 > and signs the entire transcript with the certificate verify. At this > point the client has assurance of the server's g^s. > > 2. In handshake #1, the client sends g^x and there is authentication > for g^xs and hence the client knows that any data it is sending to the > server in 0-RTT is actually going to the server. > > 3. The server provides g^y in his ServerHello and then g^xy and g^xs > are jointly used to produce the traffic keys and also to form a MAC over > the handshake. As Hugo pointed out originally, this alone should > be sufficient to authenticate the server's side of the connection and > you could omit the server CertificateVerify (Hugo, please correct > me if I have misunderstood). > > 4. However, for consistency reasons (per the discussion in Prague), > the server *also* signs the entire transcript. This authenticates > g^y (even though the MAC with g^xs already authenticated it) > and proves possession of the signing key. > > Trying to read between the lines, is your concern that the server is > now no longer explicitly signing over the ServerConfiguration in > its CertificateVerify [Note that the client continues to do so]? > And, I should note the server's certificate. -Ekr > The idea > behind removing that was to make the 1-RTT part of the handshake > more uniform regardless of whether 0-RTT data was used. > I'm certainly open to putting that back in if it's needed, but can you > explain your concern in more detail? > > > > > In addition, PR#354 (https://github.com/tlswg/tls13-spec/pull/354) >> > implements the rekey mechanism that we discussed in Yokohama. There >> > was broad agreement to adopt something like this. I would appreciate >> > it if a few people could give it a sanity check, but absent strong >> > objections, I intend to merge this PR on Friday. >> >> The restrictions on when the rekey message can be sent: Do those >> essentially boil down to "any time after sending Finished"? >> > > Except not during 0-RTT. > > > Also, I think the requirement to immediately send the KeyUpdate >> is problematic. I think it should be requirement to send it as >> next record(s). > > >> The two aren't the same: The first seemingly requires scheduling >> extra flights, which can be problematic. The second can piggyback >> on existing flights. >> > > Good suggestion. PR welcome. :) > > -Ekr > > >> >> >> -Ilari >> > > --001a114dc814e778ad0525db2c5d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 1, 2015 at 11:19 AM, Eric Rescorla <ekr@rtfm.com>= wrote:
Ilari,

<= /div>
Thanks for your quick review.

<= div class=3D"gmail_quote">On Tue, Dec 1, 2015 at 10:57 AM,= Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Tue, Dec 01, 2015 at 10:11:17AM -0800, Eric Resc= orla wrote:
>
> This clears out the big pipeline stall from PR#316, but probably has > created some bustage. Expect a series of cleanup commits and some
> other things that were head-of-line blocked this week and then
> draft-11 in the next week or so. Please file PRs and/or github
> issues for any issues you see.

Looks like the note about the PSK+ClientCert "attack" got = lost
somewhere.
=C2=A0
See the last graf of:
=C2=A0
I pointed to the e-mail by Sam's group = and also prohibit entirely
the use of cert-based client auth in p= ure PSK, since that
seemed safer. If you think more is needed her= e I would be happy
to add it.


While I don't think that is importan= t as the underlying
issue is fixed, I think there might be a note about dangers of using
server certificates in any mode where transcript and configuration
do not jointly imply SS.

=C2=A0
Actually, scanning the editor's copy, it looks VERY broken to me:
I don't see how server certificate verify (indirectly) signs on the old=
configuration. Such signing is required for security, as otherwise
SS is not impiled by signature, breaking authentication.

Previously, the document was clear about this...

<= /div>
I'm sorry, but I'm not following the issue you are= raising here. Perhaps
you could expand further? Here's m= y reasoning.

1. The server delivers the server con= figuration in handshake #0
and signs the entire transcript with t= he certificate verify. At this
point the client has assurance of = the server's g^s.

2. In handshake #1, the clie= nt sends g^x and there is authentication
for g^xs and hence the c= lient knows that any data it is sending to the
server in 0-RTT is= actually going to the server.

3. The server provi= des g^y in his ServerHello and then g^xy and g^xs
are jointly use= d to produce the traffic keys and also to form a MAC over
the han= dshake. As Hugo pointed out originally, this alone should
be suff= icient to authenticate the server's side of the connection and
you could omit the server CertificateVerify (Hugo, please correct
me if I have misunderstood).

4. However, for co= nsistency reasons (per the discussion in Prague),
the server *als= o* signs the entire transcript. This authenticates
g^y (even thou= gh the MAC with g^xs already authenticated it)
and proves possess= ion of the signing key.

Trying to read between the= lines, is your concern that the server is
now no longer explicit= ly signing over the ServerConfiguration in
its CertificateVerify = [Note that the client continues to do so]?

And, I should note the server's certific= ate.

-Ekr
=C2=A0
The idea
behind removing that was to make t= he 1-RTT part of the handshake
more uniform regardless of whether= 0-RTT data was used.=C2=A0
I'm certainly open to putting tha= t back in if it's needed, but can you
explain your concern in= more detail?



=
> In addition, PR#354 (https://github.com/tlswg/tls13= -spec/pull/354)
> implements the rekey mechanism that we discussed in Yokohama.=C2=A0 Th= ere
> was broad agreement to adopt something like this.=C2=A0 I would apprec= iate
> it if a few people could give it a sanity check, but absent strong
> objections, I intend to merge this PR on Friday.

The restrictions on when the rekey message can be sent: Do those
essentially boil down to "any time after sending Finished"?

Except not during 0-RTT.=C2=A0
<= span class=3D"">


Also, I think the requirement to immediately send the KeyUpdate
is problematic. I think it should be requirement to send it as
next record(s).=C2=A0

The two aren't the same: The first seemingly requires scheduling
extra flights, which can be problematic. The second can piggyback
on existing flights.

Good sugges= tion. PR welcome. =C2=A0:)

-Ekr




-Ilari


--001a114dc814e778ad0525db2c5d-- From nobody Tue Dec 1 12:03:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881931B2B54 for ; Tue, 1 Dec 2015 12:03:25 -0800 (PST) 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_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 OZtCzwee5ecs for ; Tue, 1 Dec 2015 12:03:23 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90321B32CF for ; Tue, 1 Dec 2015 12:02:49 -0800 (PST) Received: from pc1 (0x3ec7a652.inet.dsl.telianet.dk [::ffff:62.199.166.82]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Tue, 01 Dec 2015 21:02:46 +0100 id 0000000000000037.00000000565DFCE6.00001A5A Date: Tue, 1 Dec 2015 21:02:57 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20151201210257.64f1a7a5@pc1> In-Reply-To: References: X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-6746-1449000166-0001-2" Archived-At: Subject: Re: [TLS] Fresh results X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 20:03:25 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-6746-1449000166-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 1 Dec 2015 14:28:49 -0500 Watson Ladd wrote: > https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13Quic= Attacks.pdf >=20 > This one looks very nasty to fix. Short of disallowing the use of RSA > certificates for TLS 1.2 with the RSA handshake and in TLS 1.3, I > don't see a good fix. I haven't read this paper in detail yet. >=20 > Cross-protocol attacks are the gift that keeps giving. Correct me if I'm wrong, but as I understand the result (and I had one of the authors explaining it to me a few days ago) the problem appears only if you have a TLS 1.2 implementation with an RSA keyexchange that is vulnerable to a bleichenbacher attack. If it is not then you're fine. So as long as you make sure you implement all the proper countermeasures against that you should be fine. (Granted: This is tricky, as has been shown by previous results, even the OpenSSL implementation was lacking proper countermeasures not that long ago, but it's not impossible) Deprecating the RSA keyexchange just became a bit harder with Google's intent to deprecate DHE in Chrome and use RSA as the fallback if the host doesn't do ECDHE. --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-6746-1449000166-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWXfzxAAoJEKWIAHK7tR5CFL4P/2ipI0hOX9M6ol21gn2ynElO jjdY5pVBKD53dmmqK9cMAnSU2Ib2LL6pfzhDKGpGGyNalZ9YEg7e7NCYq9FbO+rW jbQTcSW/FQwMlEADvXlq7yJoncEGhPXqePAQMi0bV1eF8vcQqZ4Fa0HBynd3UdAV P0bMOKIjSAR3z/dUYcAZEW2oyLddodo847mFvyq6clp7r1n1ic1DZp9z5bcSxXkd ZNulD25uUmNYi7vyxgNheu+1ypMtdSz7RY9xgfconvOrcxba48huYaJnf7BVegKy t1Xny7Tq/ReqNPyV/1FiVP0gkW14nS1QDfylJQF8wm7fLaDvIpiEnVIhSo42dVOE F5pOJgjAq/84cPH1xKBB/g/TMYEt++X9gDkjfYNTldQDcU0xNNhxOXzDOzXqApbR nPyHD1VmCtVE3LAtAFJSc9id0djJDcnzN2U+tHw//u8/sFyw6D7AKhikKuTLZvSX o57sa8Va0FdyhFPQZn956fdwcaqiWQtRkrb96BPyN5BZQQ8kQDuddVW7cAg6z7Fg wzQekMsHXEgrXmeSYQbcr8vHtr9HWtc5bR2mgGFaBqYN5C3zhxCT8BambU4bylOB 7oT5d4pFufJ5zizN5xLZ2DFngf146ltZ67CSN9DAxom/zlgrkKeXPp1ErIlHaZNl YzOfbPZUTyEb6w+V8+qA =kSqe -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-6746-1449000166-0001-2-- From nobody Tue Dec 1 12:49:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6D11B37B9 for ; Tue, 1 Dec 2015 12:49:26 -0800 (PST) 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 Rh-G-rV67vCo for ; Tue, 1 Dec 2015 12:49:25 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0F91B3747 for ; Tue, 1 Dec 2015 12:49:15 -0800 (PST) Received: by lffu14 with SMTP id u14so25215698lff.1 for ; Tue, 01 Dec 2015 12:49:13 -0800 (PST) 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=gaqBsJ8yJ9mPbYqiC/0JIrjofUhHIBt065GGvwuu1sA=; b=MlM/SMVmF09ev2Q2QA0Yc2+K54QmwDOypqGE2N6+HSZWp0Zankh+V1RcKrbr1dfgVA bPnh0mBLiOGNZ7ZHO7lAkYyy5anrhmZBcSgrZx3uDeU6UH43djR2aRPmBTOorUj+0Ogi nebO6OS6jIlGL5C+JWcMtm2W+jEYtMOxn23umjBqQNaRyw00tSWBko5qb1CF38WPeZAk Zv8fu5G27RiI5koThdESayAV2Yd9h7BQb3X9nzLnATLJ2MR+PUjb32PSYhVbZdmKd0IB 16vu4tp8oOwmpIkg+awQfDIkvNS/cYXKVo0pQLdC7BcifzWlkqZJcXWR+P/5EQvw1hFR m55A== MIME-Version: 1.0 X-Received: by 10.25.22.72 with SMTP id m69mr30446812lfi.127.1449002953296; Tue, 01 Dec 2015 12:49:13 -0800 (PST) Received: by 10.25.16.98 with HTTP; Tue, 1 Dec 2015 12:49:13 -0800 (PST) In-Reply-To: <565DC935.2040607@gmail.com> References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> Date: Tue, 1 Dec 2015 23:49:13 +0300 Message-ID: From: Dmitry Belyavsky To: Bryan A Ford Content-Type: multipart/alternative; boundary=001a11407f1a4f52090525dc4a1d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 20:49:27 -0000 --001a11407f1a4f52090525dc4a1d Content-Type: text/plain; charset=UTF-8 Dear Bryan, On Tue, Dec 1, 2015 at 7:22 PM, Bryan A Ford wrote: DTLS: > > Now there's still the important question of whether this (new) proposal > could be made to work in the context of DTLS. For the DTLS case, my > current thinking is that some elements of my earlier proposal is > probably more suitable: namely using a stream cipher (or AEAD used as a > stream cipher) to encrypt and recognize the explicitly-transmitted > sequence numbers that DTLS needs. This could operate basically the same > as I described in my earlier E-mail on this topic. Note that the length > field is no longer a problem in DTLS as it is in TLS, because the > receiver already gets the length of the datagram from UDP. > > Do I understand correctly that your propose makes difficult to derive the key from the original value depending on the sequence number? -- SY, Dmitry Belyavsky --001a11407f1a4f52090525dc4a1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Bryan,=C2=A0

On Tue, Dec 1, 2015 at 7:22 PM, Bryan A Ford <bry= nosaurus@gmail.com> wrote:
DTLS:

Now there's still the important question of whether this (new) proposal=
could be made to work in the context of DTLS.=C2=A0 For the DTLS case, my current thinking is that some elements of my earlier proposal is
probably more suitable: namely using a stream cipher (or AEAD used as a
stream cipher) to encrypt and recognize the explicitly-transmitted
sequence numbers that DTLS needs.=C2=A0 This could operate basically the sa= me
as I described in my earlier E-mail on this topic.=C2=A0 Note that the leng= th
field is no longer a problem in DTLS as it is in TLS, because the
receiver already gets the length of the datagram from UDP.


Do I understand correctly that your pr= opose makes difficult to derive the key from the original value depending o= n the sequence number?

--
SY, Dmitry Bel= yavsky
--001a11407f1a4f52090525dc4a1d-- From nobody Tue Dec 1 13:46:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1281A19FA for ; Tue, 1 Dec 2015 13:46:04 -0800 (PST) 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 vr7upc48AcB0 for ; Tue, 1 Dec 2015 13:46:03 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD341A19E3 for ; Tue, 1 Dec 2015 13:46:02 -0800 (PST) Received: by wmuu63 with SMTP id u63so191179459wmu.0 for ; Tue, 01 Dec 2015 13:46:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=/jAml6NDGEApzRN5RfHWMHri9BtvHGcLS65Gnk0td/w=; b=aXcEuGRDB+vQIj4FFp+Oa4vdpbJTnbYQrkMg0PQ7lXehTDhVtdkLXQf7W/TLWO05us i/+LSQi2lEQKMA/IzbhaHJnR87gbhbAKh8q99o8LuTIwRBlmF36jE60dpbm3tOA+GBdb fSlkFJKBa71/X0Telv4afCJsDQADE3Chp6i9hb2qigk6MP6VSMMHa5h6O7ZGxfRINqb5 yH87ng2Di6NwDuNAv8ae0wb8JPPN8HQtE6TdvVvxyoPeGJDaNoNl0W0y/eED8CRpLkHG AtPWXe94CI96Gk2BmD3oKcUTLzt2M2k0q0KEjMLl/ojcyK/UAs4eTxzbNGFGWW36sgvU b0KA== X-Received: by 10.28.180.132 with SMTP id d126mr509860wmf.72.1449006361383; Tue, 01 Dec 2015 13:46:01 -0800 (PST) Received: from proz.dclient.lsne.ch (85-218-12-53.dclient.lsne.ch. [85.218.12.53]) by smtp.gmail.com with ESMTPSA id pn6sm53329972wjb.15.2015.12.01.13.45.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Dec 2015 13:45:59 -0800 (PST) To: Dmitry Belyavsky References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> From: Bryan A Ford Message-ID: <565E1517.3060209@gmail.com> Date: Tue, 1 Dec 2015 22:45:59 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030506090305060408000802" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 21:46:04 -0000 This is a cryptographically signed message in MIME format. --------------ms030506090305060408000802 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dmitry, On 12/1/15 9:49 PM, Dmitry Belyavsky wrote: > Dear Bryan,=20 >=20 > On Tue, Dec 1, 2015 at 7:22 PM, Bryan A Ford > wrote: >=20 > DTLS: >=20 > Now there's still the important question of whether this (new) prop= osal > could be made to work in the context of DTLS. For the DTLS case, m= y > current thinking is that some elements of my earlier proposal is > probably more suitable: namely using a stream cipher (or AEAD used = as a > stream cipher) to encrypt and recognize the explicitly-transmitted > sequence numbers that DTLS needs. This could operate basically the= same > as I described in my earlier E-mail on this topic. Note that the l= ength > field is no longer a problem in DTLS as it is in TLS, because the > receiver already gets the length of the datagram from UDP. >=20 >=20 > Do I understand correctly that your propose makes difficult to derive > the key from the original value depending on the sequence number? I'm not sure I understand your question; can you clarify? What is the "original value" you are worried about the key being derivable from? Certainly if the cipher (stream cipher or AEAD) is working correctly, it should make it cryptographically infeasible for an attacker to derive the shared secret key from anything the protocol transmits. Bryan --------------ms030506090305060408000802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwMTIxNDU1OVowLwYJKoZIhvcNAQkEMSIEIDHAIDGGGD6Ae+1ewUzKMVy1AMyyBJEVwfKY 05/7VBHeMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBADdtQaDRxhcNV1ju FuqLP4SM4zVFhJfcKmfLAsrwiZosH9alF/4FSXA2+nHyicyEDNzdBSoexcDomM6BqH5Mb8Eb dx2l7bSHRsEcI+wkZNMMSEGdtpif3PQMfJEnP0rM7bt8bFUxlA5lFLfzgzWrMznw39z7C7sD FtsK9byhwQl2lNOQk9hdCPEYyvFoLgEh6uqXCJ7HHEWCrDWYsfdO/EgUS13Z4BpzfX1wFIkx ng6POCnNJc62nNqW028dXP7H4cxI1UMKXmHyJh9uDWb5aIsv/vb0EjXrlY8NNAzvAsxppiiQ dd/WcNZ2MxA3DU9bTmQ7y+4GlqdMbbLTTobOZWUAAAAAAAA= --------------ms030506090305060408000802-- From nobody Tue Dec 1 15:55:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD1F1B2AEF for ; Tue, 1 Dec 2015 15:55:18 -0800 (PST) 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 nXwFSCDvXsDR for ; Tue, 1 Dec 2015 15:55:13 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98C6E1B2AEC for ; Tue, 1 Dec 2015 15:55:12 -0800 (PST) Received: by lffu14 with SMTP id u14so30120817lff.1 for ; Tue, 01 Dec 2015 15:55:10 -0800 (PST) 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=Ydi+1QB3959gzXFANEHIOGdt91tXqTTWfGoKSuV1ZBs=; b=Mh1ZzW71B8lKrOHFWlZLg9flgydQwWju8A45x4DdWNBdPixZ/bP+Oqpk+e6OuGS69h QR7IOo3Z/x5Kem3EXFOSGE49kAYtNJ7/JcLJwjlYYQC43Rkn/NYy3+ksw8NPcJGTloHk k8SL66WjYbkpbIEzEEFZuGfgh7ZMUVAPL9HcS7IknGbBtwIJfTfRKYAzqTdel8BZ9vvX vUR9LLr1DPlCJedOQV9Ey97dHspETdZ1793UxIX+SK5JUsXr9KgLkG5g5CuPTGD8iWeJ 2b3bIloKaYjTyUGUnH83Q2u9OrsfSuEfdKMi7DukUcmagp50HyuV2RvwUBgE+PCccz/3 Aivg== X-Received: by 10.25.153.146 with SMTP id b140mr140172lfe.33.1449014110762; Tue, 01 Dec 2015 15:55:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.207.135 with HTTP; Tue, 1 Dec 2015 15:54:51 -0800 (PST) In-Reply-To: <565DBC63.5090908@gmail.com> References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> From: Fabrice Gautier Date: Tue, 1 Dec 2015 15:54:51 -0800 Message-ID: To: Bryan A Ford Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 23:55:18 -0000 On Tue, Dec 1, 2015 at 7:27 AM, Bryan A Ford wrote: > On 12/1/15 4:02 AM, Fabrice Gautier wrote: >> 1) What would be the implications of this for DTLS? (Knowing that one difference between TLS and DTLS is the record header) > > Good question. Fortunately my proposal should be fairly easy to adapt > to DTLS, with one small trick. > > The main issue is that DTLS packets need to contain explicitly > transmitted sequence numbers rather than implicit sequence numbers, > because packets can be received out of the order and the receiver needs > to know which sequence number (and hence which nonce) to use to try to > decrypt and integrity-check. But if we encrypt the full DTLS header > including sequence number, how does the receiver decrypt it without > knowing the correct nonce to use to decrypt it? An apparent > chicken-and-egg problem. > > Fortunately the solution is fairly simple: the receiver simply > pre-computes and keeps in a small hash table the encrypted sequence > numbers of all packets with sequence numbers between H-W and H+W, where > H is the highest sequence number correctly received so far (the horizon) > and W is the anti-replay window size as specified in 4.1.2.5 of RFC > 4347, which typically should be 32 or 64 according to the RFC. The > receiver can precompute all these encryptions because in my proposal TLS > headers are encrypted with a stream cipher (or the AEAD operating as a > stream cipher), so it's just a matter of producing the correct > cipherstream bytes and XORing them with the uint48 sequence number. > > Whenever the receiver gets a datagram, it looks up the encrypted > sequence number in the hash table, drops it on the floor if it's not > present, and if it's present the receiver gets the decrypted sequence > number from the hash table and uses that in the AEAD decryption and > integrity-check. In the low-probability event of a hash-table collision > (i.e., two uint48 sequence numbers encrypting to the same 48-bit > ciphertext in a single 129-datagram window), the receiver can > trial-decrypt with both (or all) sequence numbers in that colliding hash > table entry. Or the receiver can keep it even simpler and just drop all > but one colliding entry, introducing a pretty low probability of > introducing occasional "false packet drops." > > The hash table is pretty trivial to maintain efficiently as well: e.g., > whenever the horizon H moves forward by delta D, remove the first D > entries from the current window and precompute another D encrypted > sequence numbers (where D will most often be 1). In the simple design > that doesn't bother dealing with hash table collisions (e.g., that > allows each hash table entry to contain only one value), perhaps don't > even bother clearing/removing old entries; just gradually overwrite them > with new ones as H moves forward. Hum.... I wouldn't qualify this as a "fairly simple" solution. > >> 2) In some implementations the record framing/parsing and encryption/decryption are down at different layers. Would this proposal make this type of implementation impossible? > > Not that I'm aware of, but I might need more information about the > specific layering approaches you're thinking of and how "strongly > enforced" that layering might be. For example: A TLS library might be logically separated into two main parts: 1) A record parsing block, that just take a stream of bytes as in input (eg: from a socket) and output a series a record. 2) A decrypt function, that take as input full encrypted record and output a decrypted one. There may be various reason to do this: flexibility, clean layering, maintainability, testability, etc... Another reason, maybe performance. For example, a network stack might not want to send partial records to the application to decrypt. Having a simple way for a network stack to implement TLS framing maybe beneficial. Currently it would be fairly simple to implement TLS record parsing in a TCP stack. But with your proposal it seems it would mean the parsing layer would need to get keys and do crypto. > But in the version of my proposal > that operates the "normal" AEAD as a stream cipher for header > encryption/decryption purposes, it doesn't seem like any change would be > needed to the standard AEAD encryption/decryption interface. It should > even be fine if the AEAD was implemented as a separate hardware module > that takes the standard AEAD interface inputs and produces the standard > AEAD outputs; as long as it supports the standard AEAD API it should be > perfectly usable in the design I proposed. > > The one potential issue I can think of if a particular, restricted API > forces the caller to commit at key-setup time to either "AEAD encryption > mode" or "AEAD decryption mode", and makes it difficult or impossible to > switch back and forth. In that case in my proposal as it stands the > receiver TLS implementation might need to set up and maintain two > hardware contexts, one for AEAD decryption (for the payloads), the other > for AEAD encryption (for stream cipher header decryption), both using > the symmetric key. This still doesn't seem all that problematic to me, > though, and I don't even know of any particular APIs offhand that > present this particular issue. This is all good, except that your proposal requires that the record parsing layers has access to some AEAD API. So far it didn't need an AEAD API at all. > Cheers > Bryan > From nobody Tue Dec 1 15:56:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9211B2AE4 for ; Tue, 1 Dec 2015 15:56:43 -0800 (PST) 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 p_-MzLyEX0TH for ; Tue, 1 Dec 2015 15:56:41 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7555F1B2AE0 for ; Tue, 1 Dec 2015 15:56:41 -0800 (PST) Received: by qgec40 with SMTP id c40so20137595qge.2 for ; Tue, 01 Dec 2015 15:56:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=pMDHuBGb3yLuIdKly2s9R/Specuh4Itb41wBnzBpBwo=; b=P3EP4euF0FrUN3j3zZONhmfdqYXWn3UlvzRV+vouGIvhcBHNbU6Q9JIsGSsb4cZrK1 Tspe0lscKebnZpnl2UL46nf8VucKy3zZ5gVqfppQYCDfHRWTznBGNY3lsF2nuE77IY8C hUw6RW1Pg3sr8xglvdhZjeNoj3WhGpnm04ev3ypuBad2ui9tUu9Slrfu3ENKLIw0CRnK gH+TV4d8/NG4uY0KM+iLS7Lg3EUarVyKTvE8GNd1smAq6X+sTP0wDPCW/LgpClZ+Fwzb d0hb9cUq9o5H/SxwoAS3AzTDUEkxz0Ih9ZPL9IMtGuucoJ0SJKaixZOkfX1Hqr9WwCay 3tBA== X-Received: by 10.140.29.33 with SMTP id a30mr294008qga.88.1449014200728; Tue, 01 Dec 2015 15:56:40 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id c48sm101622qge.49.2015.12.01.15.56.40 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 01 Dec 2015 15:56:40 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Tue, 1 Dec 2015 18:56:36 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201512011856.36501.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Fresh results X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Dec 2015 23:56:43 -0000 On Tuesday, December 01, 2015 02:28:49 pm Watson Ladd wrote: > https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf This analysis was done against TLS 1.3 draft 07 from July. It changed to RSA-PSS signatures for handshake messages in draft 09. (current is draft 11; draft 12 is pending) This doesn't seem to change anything, though. QUIC also uses PSS. > This one looks very nasty to fix. Short of disallowing the use of RSA > certificates for TLS 1.2 with the RSA handshake and in TLS 1.3, I > don't see a good fix. I haven't read this paper in detail yet. I think it's reasonable at this point to publish a diediedie RFC for plain RSA use in all TLS versions and mandate expectation of (EC)DHE with RSA (or any certificate) everywhere. This technically wouldn't apply to IE6 on XP, as that's generally using SSL3, which already got its diediedie (MS left TLS 1.0 off by default forever; anyone who can fix that can install something less than 15 years old). IE7+ on Vista+ & Java 6+ support FS RSA cipher suites. > Cross-protocol attacks are the gift that keeps giving. Or, yet another lesson that just deprecating old features with new protocols is not enough. Keeping known-weak features around forever for backwards compatibility always seems to hurt you eventually. Dave From nobody Tue Dec 1 17:24:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C541A02F1 for ; Tue, 1 Dec 2015 17:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 5pjf2BcuDwP3 for ; Tue, 1 Dec 2015 17:24:41 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BAD21B3046 for ; Tue, 1 Dec 2015 17:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1449019481; x=1480555481; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=1lx0kULs+258tXW9ODs9Y4mLVYgofZps6S0t4BH8pRs=; b=jqlqGhmxNdIWdFB5okoq8Q0g5DiSUiWBWgB8lt1uOu5pKmDJF1OpsEWU 59DYSsswOrrN6IZMnR873a5m2yF5K6hks9TRDnGI0YYoJLObto0PWd9t/ 9LqVmZ91hXbhUFct38w5hVu9qhVxNSO6nhCMEBSiJm4aHT8jEIrfn+1Ht WjJB9boGv2xQdXVvyqvFtFyxyFwDXoycwCKupHrCEL3FHfVzUMMrzRj1T IPDvlYucZLRPAUMypT/Rh6GxhmFq8u1l1CLTm4FM5NdXqkwB7dxGUYkdM yOVhWeIaWE9/FLXlSuNOSc69+JAyyf/eiIfWb6zGDIulnnDLLpe1DnbqA Q==; X-IronPort-AV: E=Sophos;i="5.20,371,1444647600"; d="scan'208";a="57158879" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe4.UoA.auckland.ac.nz) ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 Dec 2015 14:24:13 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Wed, 2 Dec 2015 14:24:12 +1300 From: Peter Gutmann To: Jacob Appelbaum , "tls@ietf.org" Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all? Thread-Index: AQHRK9MuTTIrlxrBV0e1/10aVzchP560f84AgAJn5NI= Date: Wed, 2 Dec 2015 01:24:11 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B95D5F@uxcn10-5.UoA.auckland.ac.nz> References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org>, In-Reply-To: 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: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 01:24:44 -0000 Jacob Appelbaum writes:=0A= =0A= >I think the only thing that comes close is when I've named a classified US= =0A= >government surveillance program (XKeyscore) that would probably have troub= le=0A= >with it.=0A= =0A= Why would XKeyscore have trouble with it? Standard off-the-shelf routers, = not=0A= even specialised USG surveillance gear, does fairly sophisticated flow=0A= tracing, packet reassembly, connection analysis, and so on. It's built int= o=0A= the router. Encrypting the headers is, at best, a minor speedbump to=0A= attackers (while being a major headache for implementers, particularly SSH'= s=0A= way of doing it), because they can use the native capabilities of the routi= ng=0A= hardware to sidestep the need to decrypt headers.=0A= =0A= If people really want to address this then they need to do the following:= =0A= =0A= 1. Define a threat model. What are we supposed to be defending against?=0A= =0A= (Note: The Inside-Out Threat Model, "this is the defence, anything that = it=0A= prevents is what we're defending against", is not a threat model).=0A= =0A= 2. List the various measures that can be used to defend against the threat:= =0A= Fixed-size packets, padding, quantised packet timing, etc.=0A= =0A= 3. Decide on which ones are necessary to defend against an actual threat, a= nd=0A= which ones aren't, taking into account cost/benefit tradeoffs (is the=0A= effort/overhead involved worth the gain?).=0A= =0A= 4. Provide guidance for TLS and SSH developers on how they can implement=0A= these.=0A= =0A= Once that's done (and in particular #1 and #2), we have a framework within= =0A= which we can decide whether encrypting lengths is worth the annoyance it=0A= creates for implementers.=0A= =0A= Without this, the debate over encrypted lengths is, to quote Linus, nothing= =0A= more than "people wanking around with their opinions" (and yeah, that inclu= des=0A= me).=0A= =0A= Peter.= From nobody Tue Dec 1 21:02:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E67F1A1B25 for ; Tue, 1 Dec 2015 21:02:36 -0800 (PST) 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 9Ae0fjWGR7Ek for ; Tue, 1 Dec 2015 21:02:35 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A20F1A1B23 for ; Tue, 1 Dec 2015 21:02:35 -0800 (PST) Received: by igcto18 with SMTP id to18so23630058igc.0 for ; Tue, 01 Dec 2015 21:02:34 -0800 (PST) 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=0VRc1Q421jM8j/zlRvO/h7jPHgUFZtFOiAzAGi815a0=; b=OyLwhyIA8WNxKnr2Qh8VyPmqnGvTHtwTg2py+oobV+5UY922z+0RPrvoCrkozGsBmr 5PNmy5rJSq8e58rl3B8Uuhk6mIMG1WIgmPsEdMvkJVXoe0lJTP75dDQdmxfavXAoP6DA ZBorhrFKu07Ec8dFUFLRDPT+7oFBLSO2NtFHw7Lsj0jQlMdr676tF4qt2sNVSD9ZJAwR mraIicV08fTnmW1Gj5cBojdnq7qdTUFNnZU7Fc6BpVGUK1UE3fo4xPcPZT3g3stZc8Kd 32RNmqx5WRn117Ao4Ze28Sg0hFlkoi7iNV62f34WzW9HdqnW4uOD+OMYX+GIjwSL9/Ea aOSw== MIME-Version: 1.0 X-Received: by 10.50.6.104 with SMTP id z8mr31321698igz.58.1449032554549; Tue, 01 Dec 2015 21:02:34 -0800 (PST) Received: by 10.36.155.139 with HTTP; Tue, 1 Dec 2015 21:02:34 -0800 (PST) In-Reply-To: <565DC935.2040607@gmail.com> References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> Date: Tue, 1 Dec 2015 21:02:34 -0800 Message-ID: From: Martin Thomson To: Bryan A Ford Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 05:02:36 -0000 On 1 December 2015 at 08:22, Bryan A Ford wrote: > The 2-byte length field in each record's header no longer indicates > the length of the *current* record but instead indicates the length of > the *next* record. Ensuring that you know the length of the *next* record is difficult and could dramatically degrade latency, or adding extra bogus padding or extra bogus records. For instance, I can always send in bursts of two packets, a one octet packet that promises the remainder of the burst and one that promises a single octet packet. At that point, I get to do what I've always done and you have gained little other than an increase in packet size of around 19 octets (best case). From nobody Tue Dec 1 21:31:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C941A1C00 for ; Tue, 1 Dec 2015 21:31:38 -0800 (PST) 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 Nn9BTuZov2eY for ; Tue, 1 Dec 2015 21:31:37 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C991A1BF3 for ; Tue, 1 Dec 2015 21:31:37 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B5A11284E33; Wed, 2 Dec 2015 05:31:36 +0000 (UTC) Date: Wed, 2 Dec 2015 05:31:36 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151202053136.GU18315@mournblade.imrryr.org> References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) 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, 02 Dec 2015 05:31:39 -0000 On Tue, Dec 01, 2015 at 09:02:34PM -0800, Martin Thomson wrote: > Ensuring that you know the length of the *next* record is difficult > and could dramatically degrade latency, or adding extra bogus padding > or extra bogus records. For instance, I can always send in bursts of > two packets, a one octet packet that promises the remainder of the > burst and one that promises a single octet packet. At that point, I > get to do what I've always done and you have gained little other than > an increase in packet size of around 19 octets (best case). We're missing an opportunity to implement ATM again. The magic cell size is 53 bytes, 5 bytes of header and 48 bytes of payload. With the cell length always 53 bytes, there's no longer any need to send or encrypt that length. :-) -- Viktor. From nobody Tue Dec 1 22:53:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0414E1B3391 for ; Tue, 1 Dec 2015 22:53:50 -0800 (PST) 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 luHebpkfrniw for ; Tue, 1 Dec 2015 22:53:48 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061A71B338E for ; Tue, 1 Dec 2015 22:53:48 -0800 (PST) Received: by wmuu63 with SMTP id u63so201859004wmu.0 for ; Tue, 01 Dec 2015 22:53:46 -0800 (PST) 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=RjL1HsjjRoMD76P4XBRtVomUce2IUk2K5u1dnoOfk4Y=; b=oZNby/AzgQk7WWdKTjSWkU2BfzBnYhzEhZFreXcD+ZpA16m5eqU6pI1ZCiBqOkMDoA g8lEE8588Srj+OMdcG5dgx0FGWpqWNlhNfjlC+u0f7HCQm3uvuzwwLaCOfAc30jiMFr8 zuhV+s9vYq5vXKMhyFC2ffgSvy2nlyczwlxgKei1ATxDTGHq5xSJDJsXRvPToXn4cDDy Qesth8OjhbyDoQVPEYv59Uo62Sx88sE/cKUuXmN8nZeDnJVMwq2K+7c9xc2WeB8z1zmz CynsXKY6nExUzNyVj5xVJN2RjiU0hx+0vYFqYl6xU8OkB45cuFDmoPI5vYEoo6XXkIB9 XIrQ== X-Received: by 10.28.102.8 with SMTP id a8mr3459434wmc.67.1449039226677; Tue, 01 Dec 2015 22:53:46 -0800 (PST) Received: from yoavs-mbp.mshome.net ([176.13.12.107]) by smtp.gmail.com with ESMTPSA id v196sm1742803wmv.10.2015.12.01.22.53.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Dec 2015 22:53:45 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <565DB4D9.309@gmail.com> Date: Wed, 2 Dec 2015 08:52:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <872A3889-43C7-414A-B785-4FFD6FCB0718@gmail.com> References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <3B906BDF-CA30-4EDF-ADA9-ABFC2A25014D@gmail.com> <565DB4D9.309@gmail.com> To: Bryan A Ford X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 06:53:50 -0000 > On 1 Dec 2015, at 4:55 PM, Bryan A Ford wrote: >=20 > On 12/1/15 10:12 AM, Yoav Nir wrote: >>> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum = wrote: >>> On 12/1/15, Viktor Dukhovni wrote: >>>> * Interoperable in the field with various capital-intensive >>>> middle boxen. >>>=20 >>> Which would those be? And what is the definition of = capital-intensive >>> for those watching on the sidelines? >>=20 >> Firewall, IPS/IDS devices. Boxes that attempt to perform sanity-check = on protocols to make sure that the stuff going over TCP port 443 is = really HTTPS rather than an attempt at tunneling. There are some attacks = such the the code that protects against them needs to follow TLS record = sizes. For the most part these are not-so-interesting attacks, causing = certain versions of certain browsers to hang, and they are expensive for = the firewall to protect against, so for the most part these protections = are turned off. But it=E2=80=99s not everywhere. >=20 > Certainly there are middleboxes that try to use traffic analysis to > detect attempts at tunneling - but the fact that the traffic is HTTPS > doesn't mean there's no tunneling; in fact the HTTPS CONNECT operation > does exactly that (and is sometimes used for exactly that purpose). >=20 > Regardless, does the IETF really want to be in the business of making > sure that protocols like TLS are designed to avoid making life > inconvenient for developers of Great Firewalls of whatever type? Convenience has nothing to do with it. The next version of every = firewall out there is going to support TLS 1.3. If TLS 1.3 means that = the middlebox cannot parse the record lengths, then the next version of = the middlebox will give the administrator the option of blocking TLS 1.3 = or disabling the processing that requires following record lengths. The = issue is with all older version middleboxes that are out there. They = don=E2=80=99t get updated nearly as often as we vendors would like.=20 And the IETF is in the business of developing protocols that work and = can be deployed. For counter-examples look at SCTP. It is not deployed = because middleboxes (mostly NAT devices in this case) didn=E2=80=99t = know what to do with it. It=E2=80=99s fairly simple to NAT SCTP, but the = old middleboxes didn=E2=80=99t know how. Newer middleboxes still mostly = don=E2=80=99t know how to NAT SCTP. Why? Because nobody=E2=80=99s using = SCTP, so why bother? There are a dozen other features that customers = actually want that need to be developed. >> If enough middleboxes block TLS 1.3, the browsers will implement a = downgrade dance. If they do that, attackers will be able to exploit the = downgrade dance. I don=E2=80=99t think the net effect is better = security. We=E2=80=99d be far better off writing a separate document on = how to use the padding feature that is already in 1.3 to mitigate = traffic analysis without actually flooding your Internet connection. = Splitting records and padding a few can be more effective than masking = the length bits. >=20 > Browsers have to implement a downgrade dance anyway to be able to talk > with web servers that don't support TLS 1.3. TLS 1.3 already changes > plenty of things that middleboxes "might" not like; absent concrete > evidence of major incompatibilities specifically caused by the = proposed > change, I don't see why we should avoid changing one more bit of the > protocol that middlebrowsers "might" not like. That is not what a downgrade dance is. The normal way of version = negotiation goes something like this: Client: I support TLS 1.1, 1.2, and 1.3. Server: (WTF is 1.3?) OK, I choose 1.2. By the end of the handshake both of the above messages enter the = calculation of the Finished message so it=E2=80=99s fine. A downgrade dance goes something like this: Client: I support TLS 1.1, 1.2, and 1.3. Server: (WTF is 1.3?) RST Client: (old server that didn=E2=80=99t implement version negotiation = right. Sigh) I support TLS 1.1, 1.2. Server: OK, I choose 1.2. In this case only the last two messages get into the Finished message. = As a result, an attacker (whether on-path or not) can easily induce the = downgrade dance by sending a RST, but it cannot induce version = negotiation down to 1.2. Browsers are just now getting rid of the = downgrade dance they had for 1.2. It would be a shame to have to = re-introduce it. Yoav From nobody Tue Dec 1 23:05:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F751A86E3 for ; Tue, 1 Dec 2015 23:05:09 -0800 (PST) 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 4xMwExvWBCvS for ; Tue, 1 Dec 2015 23:05:06 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAD5E1B33B0 for ; Tue, 1 Dec 2015 23:05:05 -0800 (PST) Received: by wmec201 with SMTP id c201so238783844wme.0 for ; Tue, 01 Dec 2015 23:05:04 -0800 (PST) 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=9smxgpuWyFgnba6C5YxuV1lEo6yRmuwOF2PFFqvPrQ4=; b=yO2O5Y7LvSurhpZQTJlBwn5LD++WSk27aeyohemI/4XJXlg5poT1Ct8N9PxXDf0I7x oViJC5UyPmbRO2z13CMO4OuluhZB2w7dVp0OSAQUZ0haUKuxdholRok5NqMeAzSPHSNc aZ9RXMWCqr/iU63pilJULVdYKNchfKJuJDwbApgIqdXF+xV/zfbfZCCO8ckzexRblRqD tNOIT2kXV06oHHcG7bLBQJF22Z4BsFDwAcs1epBLEB2ArKzNFdsgOTv3NOSa5RRPeQc3 Ra7otHth5ZTdxoVZtPdmdcfKJ6dMBWuBtCYRN4s2I3WjQZnsKDeLyzoj3EFvMrvNEI4d 2nlg== X-Received: by 10.194.187.179 with SMTP id ft19mr2440681wjc.176.1449039904364; Tue, 01 Dec 2015 23:05:04 -0800 (PST) Received: from yoavs-mbp.mshome.net ([176.13.12.107]) by smtp.gmail.com with ESMTPSA id z10sm29533048wmg.4.2015.12.01.23.05.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Dec 2015 23:05:03 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B95D5F@uxcn10-5.UoA.auckland.ac.nz> Date: Wed, 2 Dec 2015 09:05:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <068B1D50-CA95-4FB3-BCEB-48C20F76DBF4@gmail.com> References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4B95D5F@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 07:05:10 -0000 > On 2 Dec 2015, at 3:24 AM, Peter Gutmann = wrote: >=20 >=20 > 1. Define a threat model. What are we supposed to be defending = against? >=20 > (Note: The Inside-Out Threat Model, "this is the defence, anything = that it > prevents is what we're defending against", is not a threat model). >=20 Fine. I=E2=80=99ll take a stab at it. But different people are concerned = with different threats. So I=E2=80=99ll divide this into three layers of = concern, because I think they build one on top of the other: Concern Layer #1: I would like a passive observer to not be able to know = the exact size of requests and responses in my stream as that could = identify the resource name and content. Obvious example is from HTTPS. = At this layer I=E2=80=99m fine about =E2=80=9Cthem=E2=80=9D (for = whatever =E2=80=9Cthem=E2=80=9D I=E2=80=99m concerned about) knowing = that I am browsing Wikipedia, but I don=E2=80=99t want them to know = which article. Concern Layer #2: I would like a passive observer to not be able to know = how many requests I am making to the server at a given time. At this = level I=E2=80=99m concerned that just the number of requests may leak = something about what I am looking at. So if I=E2=80=99m looking at one = of only 12 Wikipedia pages that have exactly 27 images it severely = narrows down the list of what I=E2=80=99m looking for.=20 Concern Layer #3: I would like a passive observer to not be able to know = whether I am sending requests and getting responses at all. Obviously = they can know that I have an HTTPS connection with en.wikipedia.org, but = they should have no idea whether this connection is idle or downloading = tons of content.=20 I could add a fourth layer where I don=E2=80=99t want the observer to = know whether or not I am looking at Wikipedia at all, but that is not = something that I believe the TLS working group can do. This is more = in-line with what Jacob is doing. Yoav From nobody Wed Dec 2 00:43:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8921B346E for ; Wed, 2 Dec 2015 00:43:03 -0800 (PST) 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 YtuuYgvHT1Aj for ; Wed, 2 Dec 2015 00:43:01 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A8D91B346D for ; Wed, 2 Dec 2015 00:43:01 -0800 (PST) Received: by lfaz4 with SMTP id z4so41302136lfa.0 for ; Wed, 02 Dec 2015 00:42:59 -0800 (PST) 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=1nbMwctao5+1ZJ9JCHDkTghnZRINUgSEJwK+o2vqgAc=; b=Prp/u9EqSP2SQDSLCqc2gt8pJIE5JV73r+z6tf+fNtmwKW+m+dder+NCIWNzFQh8cd Acd9aBOPJ5o+SYlIpNCPuFwtKjNqu5cNtsiZN0Z2wNc+vuTw3zxAPYNF0wsUP42BJcLT 7x3JTghUq7uy8mrKmEnlF5wCyIhcF79A0jIb3B0BRaCk0nEDuxoijYzLa0EZqRiDubDJ nuzWJiwG3JDeLbYNX56Tgs7o0Yb8+YAPX6q77L4KIL5/3rk199UiThV4JpNVseymlZxI cqkGmtbqojtVCRySOD+P4qCYHcgiLixu1b5ReZDKY5kLk1ks775OVyhUko+QrINzDZeF xPCw== MIME-Version: 1.0 X-Received: by 10.112.130.138 with SMTP id oe10mr1300863lbb.54.1449045779621; Wed, 02 Dec 2015 00:42:59 -0800 (PST) Received: by 10.25.16.98 with HTTP; Wed, 2 Dec 2015 00:42:59 -0800 (PST) In-Reply-To: <565E1517.3060209@gmail.com> References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> <565E1517.3060209@gmail.com> Date: Wed, 2 Dec 2015 11:42:59 +0300 Message-ID: From: Dmitry Belyavsky To: Bryan A Ford Content-Type: multipart/alternative; boundary=047d7b3a88daf52c810525e64221 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 08:43:03 -0000 --047d7b3a88daf52c810525e64221 Content-Type: text/plain; charset=UTF-8 Dear Bryan, On Wed, Dec 2, 2015 at 12:45 AM, Bryan A Ford wrote: > Hi Dmitry, > > On 12/1/15 9:49 PM, Dmitry Belyavsky wrote: > > Dear Bryan, > > > > DTLS: > > > > Now there's still the important question of whether this (new) > proposal > > could be made to work in the context of DTLS. For the DTLS case, my > > current thinking is that some elements of my earlier proposal is > > probably more suitable: namely using a stream cipher (or AEAD used > as a > > stream cipher) to encrypt and recognize the explicitly-transmitted > > sequence numbers that DTLS needs. This could operate basically the > same > > as I described in my earlier E-mail on this topic. Note that the > length > > field is no longer a problem in DTLS as it is in TLS, because the > > receiver already gets the length of the datagram from UDP. > > > > > > Do I understand correctly that your propose makes difficult to derive > > the key from the original value depending on the sequence number? > > I'm not sure I understand your question; can you clarify? What is the > "original value" you are worried about the key being derivable from? > Certainly if the cipher (stream cipher or AEAD) is working correctly, it > should make it cryptographically infeasible for an attacker to derive > the shared secret key from anything the protocol transmits. > I mean something like http://tools.ietf.org/html/rfc4357#section-7 We have the keys calculated during the handshake and want to modify it for each record. -- SY, Dmitry Belyavsky --047d7b3a88daf52c810525e64221 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Bryan,=C2=A0

On Wed, Dec 2, 2015 at 12:45 AM, Bryan A Ford <brynos= aurus@gmail.com> wrote:
Hi Dmitry,

On 12/1/15 9:49 PM, Dmitry Belyavsky wrote:
> Dear Bryan,
>
>=C2=A0 =C2=A0 =C2=A0DTLS:
>
>=C2=A0 =C2=A0 =C2=A0Now there's still the important question of whe= ther this (new) proposal
>=C2=A0 =C2=A0 =C2=A0could be made to work in the context of DTLS.=C2=A0= For the DTLS case, my
>=C2=A0 =C2=A0 =C2=A0current thinking is that some elements of my earlie= r proposal is
>=C2=A0 =C2=A0 =C2=A0probably more suitable: namely using a stream ciphe= r (or AEAD used as a
>=C2=A0 =C2=A0 =C2=A0stream cipher) to encrypt and recognize the explici= tly-transmitted
>=C2=A0 =C2=A0 =C2=A0sequence numbers that DTLS needs.=C2=A0 This could = operate basically the same
>=C2=A0 =C2=A0 =C2=A0as I described in my earlier E-mail on this topic.= =C2=A0 Note that the length
>=C2=A0 =C2=A0 =C2=A0field is no longer a problem in DTLS as it is in TL= S, because the
>=C2=A0 =C2=A0 =C2=A0receiver already gets the length of the datagram fr= om UDP.
>
>
> Do I understand correctly that your propose makes difficult to derive<= br> > the key from the original value depending on the sequence number?

I'm not sure I understand your question; can you clarify?=C2=A0 = What is the
"original value" you are worried about the key being derivable fr= om?
Certainly if the cipher (stream cipher or AEAD) is working correctly, it should make it cryptographically infeasible for an attacker to derive
the shared secret key from anything the protocol transmits.



--
SY, Dmitry Belyavsky
--047d7b3a88daf52c810525e64221-- From nobody Wed Dec 2 01:07:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D701B34D8 for ; Wed, 2 Dec 2015 01:07:38 -0800 (PST) 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 FL8haCVbrVId for ; Wed, 2 Dec 2015 01:07:37 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 896D41B34AE for ; Wed, 2 Dec 2015 01:07:36 -0800 (PST) Received: by wmww144 with SMTP id w144so47584627wmw.0 for ; Wed, 02 Dec 2015 01:07:35 -0800 (PST) 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 :message-id:references:to; bh=/OgrHZ8qmbG2HT6GQyP3A5orIfwl2Yz5OFKoVvjEXIo=; b=mLTzRt5V3CoH6UGEFLDGZ5VKp+eOKzNfNFEs8vWOcbitTvWJ6aqXGDTycSkHUhVEsd H4QLB6uki0G8dLtv8T7Lodrv9RpzcAmdOoZ0LB29w2VB1YGVkfMgaZcIcY19fRbA3hk9 ggC1OVjrCZ/CEOSlbFO3+hWq2gjJb6+DCQBtD5O5XgdzZ8xp5CTClzo5dh8A1J5dA8w8 /Pp08fy7jml8PbMcE64F6SFtY8EYUgZccldmOa7OOprJNv7ebliQEjpDYfLP6GoEkTff j612F+NMP83rn9hCNYLMP/oPfe+dpNVHp5Fjsr+HAU8CXEhiwwPVQgiCuLbnkfV4jp8Z uQlw== X-Received: by 10.194.20.35 with SMTP id k3mr3102348wje.19.1449047255175; Wed, 02 Dec 2015 01:07:35 -0800 (PST) Received: from icsil1noteb193.epfl.ch (icsil1noteb193.epfl.ch. [128.178.151.41]) by smtp.gmail.com with ESMTPSA id bk2sm1834975wjc.3.2015.12.02.01.07.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Dec 2015 01:07:34 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_815073C7-14DD-4BA6-89E5-382E9BCA667A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Bryan Ford In-Reply-To: Date: Wed, 2 Dec 2015 10:07:33 +0100 Message-Id: <9BFA68AB-9677-4BE7-8F5E-D1A66EF95BA5@gmail.com> References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 09:07:39 -0000 --Apple-Mail=_815073C7-14DD-4BA6-89E5-382E9BCA667A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 02 Dec 2015, at 06:02, Martin Thomson = wrote: > On 1 December 2015 at 08:22, Bryan A Ford = wrote: >> The 2-byte length field in each record's header no longer indicates >> the length of the *current* record but instead indicates the length = of >> the *next* record. >=20 > Ensuring that you know the length of the *next* record is difficult > and could dramatically degrade latency, or adding extra bogus padding > or extra bogus records. For instance, I can always send in bursts of > two packets, a one octet packet that promises the remainder of the > burst and one that promises a single octet packet. At that point, I > get to do what I've always done and you have gained little other than > an increase in packet size of around 19 octets (best case). That type of inefficiency is extremely easy to avoid; please read the = rest of my proposal where I discussed exactly that at length. Yes, a = particularly stupid implementation could send everything in bursts of = two packets, but it=E2=80=99s ridiculously easy for a slightly smarter = implementation to avoid doing that. And what you=E2=80=99ve gained is = complete encryption and integrity-checking of the whole TLS record = before any part is interpreted, which seems like a nontrivial security = improvement. B --Apple-Mail=_815073C7-14DD-4BA6-89E5-382E9BCA667A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTEyMDIwOTA3MzNaMCMGCSqGSIb3DQEJBDEWBBSbV7fJApNCx/7737MnhcEXPHBYSTCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEATMJpz3UYMqBtKxMHUbZC7dUw4hCGepRa9fIR9Rvj4p/rhG8zdJonEbcOZg5q8Mvh 2gZaFV3hJlVL7NsKdwjo720CgKPmoKYMMOtcQ49FH8SFT9ocdSVXa0+vbwJBAUzoIoDv+NJuZ/Eb cq0tqzJRlDnw7PfqwAb3q8st/xcY7HOxlSUAWDj9erQKZh/gS2l/PHsPQjGwBCYPduru9Yq/0WE8 VCNlrCRQ5QAzhh/HgfRFRF6Z6XnXy3G/CyRfMA+AkqvFltbOPBVUQY/0jaGamhLC0WB8klpD5EEe cTgTiBfqu0FT48Ju3avbkuiQbreblaRFxEiYfu6pDeKCf3Xp8AAAAAAAAA== --Apple-Mail=_815073C7-14DD-4BA6-89E5-382E9BCA667A-- From nobody Wed Dec 2 01:11:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24541A003B for ; Wed, 2 Dec 2015 01:11:25 -0800 (PST) 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 THTh4NJjdk3i for ; Wed, 2 Dec 2015 01:11:23 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C11B1A0222 for ; Wed, 2 Dec 2015 01:11:23 -0800 (PST) Received: by wmuu63 with SMTP id u63so205841247wmu.0 for ; Wed, 02 Dec 2015 01:11:21 -0800 (PST) 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 :message-id:references:to; bh=ojM1yssoZf8RqAubbYvnEv+XKYpCNRcqZz5liY0crn4=; b=NYLU5iBXMqYEOUw2VdydMhA7WUz5fcAki4oEplsDN9NubNWA/nI+MrehNkVGJIoBSH XRUIZQ0xc0mKvtJU9X6t/opVpoYu8Yqr9mwlzZuf8tlG97gTJTrVwIO94ZgVdZY6qJs6 ZXaqFxUvrozA532k1rwRtMxCtOQ5jU5m5JEmHq+O11Xb+qVCkJh8GoMvsq8vSXP3rPI6 sjbOITuya1uL49cKyjXctpJezwkyARs8f3I/2lHbQnMYHTwnXcRPncwA5DW4spZCBEmL 3cEA3mTV7DRgmyLfXUqEKSYfcudKq/klnFvHMdE3VX5JsOLO9kkWVOPbO2XI+AF91zBy 7lrw== X-Received: by 10.28.107.26 with SMTP id g26mr44172268wmc.34.1449047481745; Wed, 02 Dec 2015 01:11:21 -0800 (PST) Received: from icsil1noteb193.epfl.ch (icsil1noteb193.epfl.ch. [128.178.151.41]) by smtp.gmail.com with ESMTPSA id w141sm29621100wmw.24.2015.12.02.01.11.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Dec 2015 01:11:20 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_AC86954F-88CA-4324-92CE-F5BA2F3CA76A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Bryan Ford In-Reply-To: Date: Wed, 2 Dec 2015 10:11:19 +0100 Message-Id: <9BDDC23D-1039-4C75-BF32-57330317BCAB@gmail.com> References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> <565E1517.3060209@gmail.com> To: Dmitry Belyavsky X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 09:11:26 -0000 --Apple-Mail=_AC86954F-88CA-4324-92CE-F5BA2F3CA76A Content-Type: multipart/alternative; boundary="Apple-Mail=_5B180F2D-2C1A-4499-8DA5-189715BC3002" --Apple-Mail=_5B180F2D-2C1A-4499-8DA5-189715BC3002 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 02 Dec 2015, at 09:42, Dmitry Belyavsky wrote: > On Wed, Dec 2, 2015 at 12:45 AM, Bryan A Ford > wrote: > On 12/1/15 9:49 PM, Dmitry Belyavsky wrote: > > Dear Bryan, > > > > DTLS: > > > > Now there's still the important question of whether this (new) = proposal > > could be made to work in the context of DTLS. For the DTLS = case, my > > current thinking is that some elements of my earlier proposal is > > probably more suitable: namely using a stream cipher (or AEAD = used as a > > stream cipher) to encrypt and recognize the = explicitly-transmitted > > sequence numbers that DTLS needs. This could operate basically = the same > > as I described in my earlier E-mail on this topic. Note that = the length > > field is no longer a problem in DTLS as it is in TLS, because = the > > receiver already gets the length of the datagram from UDP. > > > > > > Do I understand correctly that your propose makes difficult to = derive > > the key from the original value depending on the sequence number? >=20 > I'm not sure I understand your question; can you clarify? What is the > "original value" you are worried about the key being derivable from? > Certainly if the cipher (stream cipher or AEAD) is working correctly, = it > should make it cryptographically infeasible for an attacker to derive > the shared secret key from anything the protocol transmits. >=20 > I mean something like http://tools.ietf.org/html/rfc4357#section-7 = > We have the keys calculated during the handshake and want to modify it = for each record.=20 Hmmm - the RFC you point to is about the GOST cipher, and section 7 = seems to be about =E2=80=9Csecret key diversification=E2=80=9D, but I = know nothing about GOST other than that it=E2=80=99s a cipher and it=E2=80= =99s not obvious to me what exactly =E2=80=9Csecret key = diversification=E2=80=9D means here or what exactly it has to do with = TLS (which works with many different ciphers). I guess I still need a = more detailed clarification of your question if I=E2=80=99m going to be = able to try to answer it. B >=20 >=20 > --=20 > SY, Dmitry Belyavsky --Apple-Mail=_5B180F2D-2C1A-4499-8DA5-189715BC3002 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On 02 Dec 2015, at 09:42, Dmitry Belyavsky <beldmit@gmail.com> = wrote:
On Wed, Dec 2, 2015 at 12:45 AM, Bryan A Ford = <brynosaurus@gmail.com> = wrote:
On 12/1/15 9:49 PM, = Dmitry Belyavsky wrote:
> Dear Bryan,
>
>    =  DTLS:
>
>     Now there's still the important question of = whether this (new) proposal
>     could be made to work in the context of = DTLS.  For the DTLS case, my
>     current thinking is that some elements of my = earlier proposal is
>     probably more suitable: namely using a stream = cipher (or AEAD used as a
>     stream cipher) to encrypt and recognize the = explicitly-transmitted
>     sequence numbers that DTLS needs.  This = could operate basically the same
>     as I described in my earlier E-mail on this = topic.  Note that the length
>     field is no longer a problem in DTLS as it is in = TLS, because the
>     receiver already gets the length of the datagram = from UDP.
>
>
> Do I understand correctly that your propose makes difficult to = derive
> the key from the original value depending on the sequence = number?

I'm not sure I understand your question; can you clarify?  = What is the
"original value" you are worried about the key being derivable from?
Certainly if the cipher (stream cipher or AEAD) is working correctly, = it
should make it cryptographically infeasible for an attacker to derive
the shared secret key from anything the protocol transmits.

I mean something like http://tools.ietf.org/html/rfc4357#section-7
We have the keys calculated during the handshake and want to = modify it for each = record. 

Hmmm - the RFC you point to is about the GOST = cipher, and section 7 seems to be about =E2=80=9Csecret key = diversification=E2=80=9D, but I know nothing about GOST other than that = it=E2=80=99s a cipher and it=E2=80=99s not obvious to me what exactly = =E2=80=9Csecret key diversification=E2=80=9D means here or what exactly = it has to do with TLS (which works with many different ciphers).  I = guess I still need a more detailed clarification of your question if = I=E2=80=99m going to be able to try to answer it.

B



--
SY, = Dmitry Belyavsky

= --Apple-Mail=_5B180F2D-2C1A-4499-8DA5-189715BC3002-- --Apple-Mail=_AC86954F-88CA-4324-92CE-F5BA2F3CA76A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTEyMDIwOTExMjBaMCMGCSqGSIb3DQEJBDEWBBSn6c7igS0aEE4S4aewaeyn4+Ne0zCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAT9o1mvuM+ZO9qfQGPNOXYI/k1Zd+gbiOyKeuZSujJsRwPBcv9R+zS1UMcgJARxS6 Nz0qo2LX82iow8Em/DXME3Y+rCmQXkaGywZXtdA4LPiWW5NilXToDzS4VrN/r+yZlDxw5cIeAOug /Pwi4yXvRqC6ubuP0lE3RIs2WUQbzgu5ke/az1rCVuGcAa6APjuL5ihkeZeBt16eawf5Mn81qDe4 PSfhelxOgPMOS7CG3RJZOJeHL+kcLFVuCE02xNfjUDle1F642IRkBENWOxSdvKijlNM8/Ws65yVe Oe6sVaeDT8NzJGMlfNJilixgOAlmq//n2JvsXEt/sMbPIelEMAAAAAAAAA== --Apple-Mail=_AC86954F-88CA-4324-92CE-F5BA2F3CA76A-- From nobody Wed Dec 2 01:52:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE32B1A6FE5 for ; Wed, 2 Dec 2015 01:52:01 -0800 (PST) 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 d0fzKOCK7CAi for ; Wed, 2 Dec 2015 01:51:59 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F2C1A6FDC for ; Wed, 2 Dec 2015 01:51:58 -0800 (PST) Received: by wmww144 with SMTP id w144so49125005wmw.0 for ; Wed, 02 Dec 2015 01:51:57 -0800 (PST) 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 :message-id:references:to; bh=25NdJIJYqp/c3BrHshjXjyERYD5M9XxQuC1GrVrYxfQ=; b=hSYMt0Q33NU4B7/Yf8pg/sSNWKvn596MUlXH/SKp3IFvZWmgUjDs4qHKDqqY/FxXCx /nmMelJ0z/tK2vQjZ8tGXJ6JG7/qg0eFUEj43NdV+Lz9AMuCszwvud5Sac8hIJhdhJnJ kUKMyAjoy15w8fxoUNqcVDNl8H6IzOzVlmLviYDjhKsYTEY2cWyqj43FPTAfynhB/8Vv kfpQHEWAmeRmVvMTN5kJA6+MTKjJXf2Mvlp43VLgRnKoUDWsdxPWU6wTEWP4uIz7nX5m Dgpr3Qg1XMY9L/HoIgQ2Gy8TxTh6HjUtwHwTz2h3+CumINbkcmMAh7Q1SWgYMws88lEL +OSg== X-Received: by 10.194.191.134 with SMTP id gy6mr3596654wjc.173.1449049917480; Wed, 02 Dec 2015 01:51:57 -0800 (PST) Received: from icsil1noteb193.epfl.ch (icsil1noteb193.epfl.ch. [128.178.151.41]) by smtp.gmail.com with ESMTPSA id h189sm30146179wme.1.2015.12.02.01.51.56 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Dec 2015 01:51:56 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_AC36E91B-075A-4556-B367-8D422F19D759"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Bryan Ford In-Reply-To: Date: Wed, 2 Dec 2015 10:51:55 +0100 Message-Id: <1D68EFC9-D5A5-4501-AD7D-0B744AB7428C@gmail.com> References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> To: Fabrice Gautier X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 09:52:02 -0000 --Apple-Mail=_AC36E91B-075A-4556-B367-8D422F19D759 Content-Type: multipart/alternative; boundary="Apple-Mail=_DFDB47AF-8425-415A-8D9D-F74C763B1C31" --Apple-Mail=_DFDB47AF-8425-415A-8D9D-F74C763B1C31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 02 Dec 2015, at 00:54, Fabrice Gautier = wrote: > On Tue, Dec 1, 2015 at 7:27 AM, Bryan A Ford > wrote: >> On 12/1/15 4:02 AM, Fabrice Gautier wrote: >>> 1) What would be the implications of this for DTLS? (Knowing that = one difference between TLS and DTLS is the record header) >>=20 >> Good question. Fortunately my proposal should be fairly easy to = adapt >> to DTLS, with one small trick. [=E2=80=A6] >=20 > Hum.... I wouldn't qualify this as a "fairly simple" solution. A reasonable but subjective position, which I think we should further = discuss later if/when this (or some) WG actually revisits DTLS. :) >>> 2) In some implementations the record framing/parsing and = encryption/decryption are down at different layers. Would this proposal = make this type of implementation impossible? >>=20 >> Not that I'm aware of, but I might need more information about the >> specific layering approaches you're thinking of and how "strongly >> enforced" that layering might be. >=20 > For example: > A TLS library might be logically separated into two main parts: > 1) A record parsing block, that just take a stream of bytes as in > input (eg: from a socket) and output a series a record. > 2) A decrypt function, that take as input full encrypted record and > output a decrypted one. >=20 > There may be various reason to do this: flexibility, clean layering, > maintainability, testability, etc... >=20 > Another reason, maybe performance. For example, a network stack might > not want to send partial records to the application to decrypt. Having > a simple way for a network stack to implement TLS framing maybe > beneficial. Currently it would be fairly simple to implement TLS > record parsing in a TCP stack. But with your proposal it seems it > would mean the parsing layer would need to get keys and do crypto. In my first proposal, with headers encrypted with a stream cipher (or = AEAD used as one), I think this kind of layering should still be quite = feasible, with the one caveat that the TLS record parsing layer does = indeed need to make one new =E2=80=9Ccall=E2=80=9D into the = crypto-related code (to get the header) in addition to the one it = already does (to pass the body and header to the crypto code for = body-decryption and integrity-check). And only on the receive path; the = send path seems pretty much unaffected. This doesn=E2=80=99t seem like = a big layering problem to me, but again subjective opinions may vary. In my second proposal, with headers fully encrypted and = integrity-checked along with the body, I think the opportunity for the = clean layering you propose comes back and perhaps gets even better: = it=E2=80=99s just that the record writing/parsing now happens *inside* = rather than outside the encryption boundary. In other words, their = order is reversed: the sender invokes the record-writing code first, = then the AEAD encryption code to encrypt everything (header and data) at = once; the receiver flow invokes the AEAD decryption code first to = decrypt everything, then invokes the separately-modularized record = parsing code on the already fully decrypted and integrity-checked record = content. This seems even cleaner to me than the current approach, where = the record parsing code has to do some (very careful!) parsing of the = record before it=E2=80=99s been authenticated, then invoke decryption, = then do some more internal parsing on the decrypted AEAD body (e.g., the = encrypted content-type within). B= --Apple-Mail=_DFDB47AF-8425-415A-8D9D-F74C763B1C31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On 02 Dec 2015, at 00:54, Fabrice Gautier <fabrice.gautier@gmail.com> wrote:
On Tue, Dec 1, 2015 at = 7:27 AM, Bryan A Ford <brynosaurus@gmail.com> wrote:
On = 12/1/15 4:02 AM, Fabrice Gautier wrote:
1) What would be the implications of this for = DTLS? (Knowing that one difference between TLS and DTLS is the record = header)

Good question. =  Fortunately my proposal should be fairly easy to adapt
to DTLS, with one small trick. [=E2=80=A6]

Hum.... I wouldn't qualify this as a "fairly = simple" solution.

A = reasonable but subjective position, which I think we should further = discuss later if/when this (or some) WG actually revisits DTLS. = :)

2) In some = implementations the record framing/parsing and encryption/decryption are = down at different layers. Would this proposal make this type of = implementation impossible?

Not = that I'm aware of, but I might need more information about the
specific layering approaches you're thinking of and how = "strongly
enforced" that layering might be.

For example:
 A TLS library might be logically = separated into two main parts:
1) A record parsing block, that just take = a stream of bytes as in
input (eg: from a socket) and output a series a = record.
2) A decrypt function, that take as input full = encrypted record and
output a decrypted one.

There may be various reason to do this: = flexibility, clean layering,
maintainability, testability, etc...

Another reason, maybe performance. For = example, a network stack might
not want to send partial records to the = application to decrypt. Having
a simple way for a network stack to = implement TLS framing maybe
beneficial. Currently it would be fairly simple = to implement TLS
record parsing in a TCP stack. But with your = proposal it seems it
would mean the parsing layer would need to get = keys and do crypto.

In my first = proposal, with headers encrypted with a stream cipher (or AEAD used as = one), I think this kind of layering should still be quite feasible, with = the one caveat that the TLS record parsing layer does indeed need to = make one new =E2=80=9Ccall=E2=80=9D into the crypto-related code (to get = the header) in addition to the one it already does (to pass the body and = header to the crypto code for body-decryption and integrity-check). =  And only on the receive path; the send path seems pretty much = unaffected.  This doesn=E2=80=99t seem like a big layering problem = to me, but again subjective opinions may vary.

In my second proposal, with headers fully = encrypted and integrity-checked along with the body, I think the = opportunity for the clean layering you propose comes back and perhaps = gets even better: it=E2=80=99s just that the record writing/parsing now = happens *inside* rather than outside the encryption boundary.  In = other words, their order is reversed: the sender invokes the = record-writing code first, then the AEAD encryption code to encrypt = everything (header and data) at once; the receiver flow invokes the AEAD = decryption code first to decrypt everything, then invokes the = separately-modularized record parsing code on the already fully = decrypted and integrity-checked record content.  This seems even = cleaner to me than the current approach, where the record parsing code = has to do some (very careful!) parsing of the record before it=E2=80=99s = been authenticated, then invoke decryption, then do some more internal = parsing on the decrypted AEAD body (e.g., the encrypted content-type = within).

B
= --Apple-Mail=_DFDB47AF-8425-415A-8D9D-F74C763B1C31-- --Apple-Mail=_AC36E91B-075A-4556-B367-8D422F19D759 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTEyMDIwOTUxNTZaMCMGCSqGSIb3DQEJBDEWBBRMguvqJVp13IP/cg3bHRPm70bCoTCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAjjg0sNSXF5/9uacLHlFH8QP1WLZkbrLJTepls+PhMxBws9ijnmUNTH9bWLowXxYf NwSYNpcTE0hTLT6DzKQvhOkFn8aZaWCOKTxtX2j2zmNJMBEYNKKRt5dxFlAN324BeNEqFw5TTms7 o/w9ufVOdgCN9XkCQsdCr2Tp1k6Ct/upC3TQAZJhJW+Qpd8HZCXedZFhHMt2TqCtORJ4oFLBnmvR /Eh7zcyrccGwGnaCdYM9ToURcrAuFo5605VuO+J1ER1MuOCRhCID1Kggofs1wa8oEBA5b5k3lzwM oaSPzrGI/WrjZPO4lESSKec4GDJ1KZ+UtFKFKBLQkbBHvQ7JlwAAAAAAAA== --Apple-Mail=_AC36E91B-075A-4556-B367-8D422F19D759-- From nobody Wed Dec 2 02:03:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EB51A7012 for ; Wed, 2 Dec 2015 02:03:48 -0800 (PST) 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 onAgc12-gJUX for ; Wed, 2 Dec 2015 02:03:45 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99391A700D for ; Wed, 2 Dec 2015 02:03:44 -0800 (PST) Received: by wmvv187 with SMTP id v187so246688608wmv.1 for ; Wed, 02 Dec 2015 02:03:43 -0800 (PST) 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 :message-id:references:to; bh=wU6RT2nKOOG9EZncPgx+MnsEOXhLVc/dq4zusR3HFnY=; b=JO5Wd2BphhkvTFWwX8vLnmP9RIxFsBm1p/IF4NhFa71WQ5utWIHIWDQPQXkA2ZHPe2 bg2CDk2bs+d7wwhH9rlG/qaqZpppvf62q9AOEMg0K6p0UmCG6XWTsKqa1TKzSKLPHMRP 6XhSLtYCCKLpX3zjg8NBNa8xIwvwItFnkYQw7YLLPTH+plJQC1eFFIU3EssmZBnJHMwL eldTZliyoYEieNcSy/0KFQSK17QvIro14ds1m3P31UtdAkH+3FVCCRWFxKBg4ptYCuqG Kn2qkIp3jX53bysRgvfhiJP0MzSrY8Clni6FBR6yfmfAXBBIlZOqH4mpDqsUGemTewuo d00A== X-Received: by 10.28.100.69 with SMTP id y66mr43373028wmb.98.1449050623476; Wed, 02 Dec 2015 02:03:43 -0800 (PST) Received: from icsil1noteb193.epfl.ch (icsil1noteb193.epfl.ch. [128.178.151.41]) by smtp.gmail.com with ESMTPSA id h5sm2023281wjz.21.2015.12.02.02.03.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Dec 2015 02:03:41 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_1C6FA78C-AD92-4027-B02D-7A4321012FB7"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Bryan Ford In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B95D5F@uxcn10-5.UoA.auckland.ac.nz> Date: Wed, 2 Dec 2015 11:03:41 +0100 Message-Id: References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4B95D5F@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 10:03:48 -0000 --Apple-Mail=_1C6FA78C-AD92-4027-B02D-7A4321012FB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 02 Dec 2015, at 02:24, Peter Gutmann = wrote: > Jacob Appelbaum writes: >> I think the only thing that comes close is when I've named a = classified US >> government surveillance program (XKeyscore) that would probably have = trouble >> with it. >=20 > Why would XKeyscore have trouble with it? Standard off-the-shelf = routers, not > even specialised USG surveillance gear, does fairly sophisticated flow > tracing, packet reassembly, connection analysis, and so on. It's = built into > the router. Encrypting the headers is, at best, a minor speedbump to > attackers (while being a major headache for implementers, particularly = SSH's > way of doing it), because they can use the native capabilities of the = routing > hardware to sidestep the need to decrypt headers. >=20 > If people really want to address this then they need to do the = following: >=20 > 1. Define a threat model. What are we supposed to be defending = against? >=20 > (Note: The Inside-Out Threat Model, "this is the defence, anything = that it > prevents is what we're defending against", is not a threat model). We have repeatedly stated several relevant threat models here; you just = don=E2=80=99t seem to be accepting them as threat models for some = reason. One is the passive eavesdropping attacker, who can monitor = flows but cannot easily inject traffic; mass monitoring of tapped fibre = optic cables are one specific real-world example of that. Another is = the =E2=80=9Cpartly-active=E2=80=9D attacker who can inject packets but = cannot readily prevent the legitimate packets from arriving; two very = real-world examples of this are XKEYSCORE/QUANTUMINSERT and the WiFi = internet cafe snooper. In each of these real-world threat models the = =E2=80=9Cdribble attack=E2=80=9D to sniff out record boundaries via full = MITM is not an option for the attacker, and hence there is potential = benefit to encrypted record headers even without any other = anti-traffic-analysis measures. > 2. List the various measures that can be used to defend against the = threat: > Fixed-size packets, padding, quantised packet timing, etc. We have been doing this as well, repeatedly. And as I=E2=80=99ve stated = repeatedly and you have not refuted, having encrypted packet headers = allows us to deploy some of those defense measures in multiple places in = the network (e.g., TCP stack and/or middle boxes) rather than just one = (TLS implementation). B= --Apple-Mail=_1C6FA78C-AD92-4027-B02D-7A4321012FB7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTEyMDIxMDAzNDFaMCMGCSqGSIb3DQEJBDEWBBSjwix8s97n8V78cPzZ/s6vKmAFgjCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEARqe+22ffSUodkUDVjI93hJmX5OIqclgdwmuumkvQIWH4GNEN3e2afW9Hm/5yqnDR R/vthfpV4DU44oGky77rBvuIyZ8B/3yEVmakoCyafXXz+LgaJRS+Urcn8WKteYOTOvlsngUgFbUS PehOASusXOnldogTBMYaXyrSDMrwMxhPshy2FNya0w8F60istzp80TGnyx1lOFlLhY/aKrjFg4Tm cpEcwgARxiTtdfZyScobYWm9Vk/COrY/BdQoBer6XpNjLTOxmZ+wyEzWFobU8KpTpqDlkfBtXZxX gCuRZ9FL6f3i+ekVMCTDA8dvcvtJGsrr+XFHaPjs3U8Y4GkgsAAAAAAAAA== --Apple-Mail=_1C6FA78C-AD92-4027-B02D-7A4321012FB7-- From nobody Wed Dec 2 02:14:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776781A7D85 for ; Wed, 2 Dec 2015 02:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-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 K_-0gRdidwrU for ; Wed, 2 Dec 2015 02:14:46 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF6C1A710C for ; Wed, 2 Dec 2015 02:14:45 -0800 (PST) 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 (Postfix) with ESMTPS id 580E913595; Wed, 2 Dec 2015 10:14:45 +0000 (UTC) Received: from dhcp-10-40-3-116.brq.redhat.com (dhcp-10-40-3-116.brq.redhat.com [10.40.3.116]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB2AEgWK024863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 Dec 2015 05:14:44 -0500 Message-ID: <1449051281.4345.31.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Hanno =?ISO-8859-1?Q?B=F6ck?= , tls@ietf.org Date: Wed, 02 Dec 2015 11:14:41 +0100 In-Reply-To: <20151201210257.64f1a7a5@pc1> References: <20151201210257.64f1a7a5@pc1> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: Re: [TLS] Fresh results X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 10:14:47 -0000 On Tue, 2015-12-01 at 21:02 +0100, Hanno Böck wrote: > On Tue, 1 Dec 2015 14:28:49 -0500 > Watson Ladd wrote: > > > https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls > > 13QuicAttacks.pdf > > > > This one looks very nasty to fix. Short of disallowing the use of > > RSA > > certificates for TLS 1.2 with the RSA handshake and in TLS 1.3, I > > don't see a good fix. I haven't read this paper in detail yet. > > > > Cross-protocol attacks are the gift that keeps giving. > > Correct me if I'm wrong, but as I understand the result (and I had > one > of the authors explaining it to me a few days ago) the problem > appears > only if you have a TLS 1.2 implementation with an RSA keyexchange > that > is vulnerable to a bleichenbacher attack. If it is not then you're > fine. The interesting result of the paper is: "Even though this limits the practical  impact  of  this  attack,  it  demonstrates  that  simply removing a legacy algorithm from a standard is not necessarily sufficient to protect against its weaknesses." Even though the attack does not work for current implementations it underlines that if you reuse keys from TLS 1.2 to TLS 1.3 you don't get any advantage from the better algorithms in TLS 1.3. You are as safe, as if you'd be using TLS 1.2. That can be claimed to be trivial result given that it is underlined on almost every paper that describes a cross-protocol attack, but it is not still grasped by the engineering community. There have been described quite some cross protocol attacks (Kerberos 4 -> Kerberos 5 by Yu et al., TLS between ciphersuites starting by Wagner and Schneier), but still we reuse keys between protocols. regards, Nikos From nobody Wed Dec 2 02:47:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC9E1A878A for ; Wed, 2 Dec 2015 02:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 yDZPy9HKucz9 for ; Wed, 2 Dec 2015 02:47:26 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 7EA131A8778 for ; Wed, 2 Dec 2015 02:47:26 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id A6DD09D66FC3B; Wed, 2 Dec 2015 10:47:22 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id tB2AlL7B003252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Dec 2015 11:47:23 +0100 Received: from FR712WXCHMBA13.zeu.alcatel-lucent.com ([169.254.5.200]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 2 Dec 2015 11:47:07 +0100 From: "GUBALLA, JENS (JENS)" To: Bryan A Ford , Fabrice Gautier Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all? Thread-Index: AQHRLEzU2k6BjHO6ykivH825T94vhJ63f/ig Date: Wed, 2 Dec 2015 10:47:06 +0000 Message-ID: <547EE95EB794FD4DB8062F7A4C86D0BC4A39F163@FR712WXCHMBA13.zeu.alcatel-lucent.com> References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> In-Reply-To: <565DBC63.5090908@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0223_01D12CF7.2AF664B0" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 10:47:28 -0000 ------=_NextPart_000_0223_01D12CF7.2AF664B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > Fortunately the solution is fairly simple: the receiver simply pre- > computes and keeps in a small hash table the encrypted sequence numbers > of all packets with sequence numbers between H-W and H+W, where H is > the highest sequence number correctly received so far (the horizon) and > W is the anti-replay window size as specified in 4.1.2.5 of RFC 4347, > which typically should be 32 or 64 according to the RFC. The receiver > can precompute all these encryptions because in my proposal TLS headers > are encrypted with a stream cipher (or the AEAD operating as a stream > cipher), so it's just a matter of producing the correct cipherstream > bytes and XORing them with the uint48 sequence number. > > Whenever the receiver gets a datagram, it looks up the encrypted > sequence number in the hash table, drops it on the floor if it's not > present, and if it's present the receiver gets the decrypted sequence > number from the hash table and uses that in the AEAD decryption and > integrity-check. In the low-probability event of a hash-table > collision (i.e., two uint48 sequence numbers encrypting to the same 48- > bit ciphertext in a single 129-datagram window), the receiver can > trial-decrypt with both (or all) sequence numbers in that colliding > hash table entry. Or the receiver can keep it even simpler and just > drop all but one colliding entry, introducing a pretty low probability > of introducing occasional "false packet drops." > > The hash table is pretty trivial to maintain efficiently as well: e.g., > whenever the horizon H moves forward by delta D, remove the first D > entries from the current window and precompute another D encrypted > sequence numbers (where D will most often be 1). In the simple design > that doesn't bother dealing with hash table collisions (e.g., that > allows each hash table entry to contain only one value), perhaps don't > even bother clearing/removing old entries; just gradually overwrite > them with new ones as H moves forward. [JG] In case there is a packet loss of at least W subsequent DTLS records: How can the receiver then ever adjust its hash table? Wouldn't that mean that no records at all would be accepted anymore? Best regards, Jens ------=_NextPart_000_0223_01D12CF7.2AF664B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/DCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYjCCBkqgAwIBAgIKE1mSVAAAAADt+zANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDI0MDYyNDM5WhcNMTcwNDIz MDYyNDM5WjBCMRAwDgYDVQQDEwdsdnBzYWFlMS4wLAYJKoZIhvcNAQkBFh9qZW5zLmd1YmFsbGFA YWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuZZTGrNK 9hSyYEI9w2lnABbWQBeU1DyJ9jX33JSOfgMGYaQ0ZZZFRwX5vDIgj499CxaWmpImbQTxdYa/vxpS U7SfqtYF7B2AB2irUYdCu/GGjTqHaXmPyyktPaiEOgR7AOz8oXxUdaECsKmTBANOpkE1J6yA3KPJ Yxde3h5bTqnjxvJB5IJhr9rIvcf5V3v6ZyW0MHOkDXn20xjEDJVMVdhhjlnwM4WmUiA/SNq7IiQ8 elmivF5NuEK9mwZEXqkR6aXHVcgPc1fuMxwsxJbdfdmMyIDV62kSTVlb/iXNJDByQJ/GRnuYHCFA qIld1HgdJCpECl+ohveGLG46CvD6iwIDAQABo4IEFDCCBBAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIhb3FWYPjsTmHpYEqhr/DQoWUmBmBC/nmTIT9tVoCAWQCAQUwHwYDVR0lBBgwFgYKKwYB BAGCNwoDBAYIKwYBBQUHAwQwCwYDVR0PBAQDAgWgMCkGCSsGAQQBgjcVCgQcMBowDAYKKwYBBAGC NwoDBDAKBggrBgEFBQcDBDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG 9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFPUv0vuw2MQvQ81rxR/PDOlK po4KMB8GA1UdIwQYMBaAFNnsa72WWCL32KZ3zf5Nge+6l70SMIIBXQYDVR0fBIIBVDCCAVAwggFM oIIBSKCCAUSGgdlsZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQlMjBJbnRlcm5hbCUyMFN1YiUy MENBLENOPXVzbmF2c3BraTAzcCxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1sdWFkLERDPWx1Y2VudCxEQz1jb20/Y2VydGlm aWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50 hixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNybIY4aHR0cDovL3Nl cnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmwwggFhBggrBgEF BQcBAQSCAVMwggFPMIHMBggrBgEFBQcwAoaBv2xkYXA6Ly8vQ049QWxjYXRlbCUyMEx1Y2VudCUy MEludGVybmFsJTIwU3ViJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NBQ2Vy dGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDgGCCsGAQUF BzAChixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNydDBEBggrBgEF BQcwAoY4aHR0cDovL3NlcnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJD QS5jcnQwKgYDVR0RBCMwIYEfamVucy5ndWJhbGxhQGFsY2F0ZWwtbHVjZW50LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAXRHvujXQqqJMH1wCrG+0UrRv0v7CpjhIyuLwJ5XDhTj9JcKsYLpWREi/zXhN Sy6TC61uUKLrAuX0uXAXW0zsBYgPDFkq481gTgdxG/brcg8lXF8Xm787ixPR8Mp8j80ZHZ5OnA1k +Xuw/QPsE4wp8RZrjqvoJQpSXtXPdX3+XBE0VsANBYszCWfrR0ByI4hZ9Saoc26umYnOY8sU0UZ/ 1XnEcRfUmVWRxTydYAFdTtOHRjBn3V7TZnfeGYpKSxrqdh6nTqk0FR832p8Z8RyNjEv3qdaX9BK7 jsjQgGNH0gxWPf+wARDdk5abnalyChTjv8B70KeLOYbsrF0greiw3TGCBCkwggQlAgEBMIGUMIGF MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPy LGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVj ZW50IEludGVybmFsIFN1YiBDQQIKE1mSVAAAAADt+zAJBgUrDgMCGgUAoIICaTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMDIxMDQ3MDVaMCMGCSqGSIb3DQEJ BDEWBBRCd5cyvvc/EFpKzJAuGQ8fszfYzDCBpQYJKwYBBAGCNxAEMYGXMIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKE1mSVAAAAADt+zCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYUxEzARBgoJkiaJ k/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAy MRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJu YWwgU3ViIENBAgoTWZJUAAAAAO37MIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJYIZIAWUDBAEqMAsG CWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzAL BglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAJcz Kmo2s9PXSufnbCo4SFlYmvPB4kIObDIKX5Jsc04F5FahtsW5WQrow60vy7/62uahyarNhaLKpdhg 2IFgybuVkPgvvL/O6aXC825LxaeD/N35NZkzQhVJvr+n9f3fQKK46sLeUIf6h/fDEk2ItNUeoUuy n5IDTH2dHmw7p1SNu68xkI51ECMIWNBA9zOHdygHynE9iziro4n/cOhj5vEA3wNONs6K19c7dEkf UJ/azVuqZ9ZEXikCpIQBvQrhzw7oZbmBiRTGQh2V40cR4yax9/VeJsJtLlZJsgb27AuPMJ2vYkMY /YNszeCmt1aSEyKwFlK7uggcTKgugqoJwTsAAAAAAAA= ------=_NextPart_000_0223_01D12CF7.2AF664B0-- From nobody Wed Dec 2 03:38:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643F81A8700 for ; Wed, 2 Dec 2015 03:38:45 -0800 (PST) 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] 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 WjCckFO_DdIl for ; Wed, 2 Dec 2015 03:38:44 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAF3D1A6F9C for ; Wed, 2 Dec 2015 03:38:43 -0800 (PST) Received: by iofh3 with SMTP id h3so42349693iof.3 for ; Wed, 02 Dec 2015 03:38:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=g/6wSLEUOTFEUOHS06zk0eZ8KFlp3UAAJX1qdWVB368=; b=iHQK+NomNQDxpRlKm5JT017tWTabMe2NsC9nb9NQb3kvFZzj9FJNrd/UP02YWoe21K hllu5sLALD5Zk0pH0XlYx5MRUsWHH04WilRg70K7PEX09Uh1jgTTHwlOGKKuefJzhHBi yYIMEpPhcu3/p7gy6HOswGYJB53IuUx1gqVxV0p+pmmv3G0hy2Qsva92Vejw9TUJhrs6 YOdDRzkfEaVlFp9D3jgYqNEXRS+9J4qBwzfeWcj5rO7XEgyxjk8gAdfgpXgBq/8aAo2n wLlVGzdlnrdpeS3l1wlO6XvT+Gvg1zsAIzQkJZhUqbOeZNJdTOEseQSJQC8r0xT215/y DRPA== 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=g/6wSLEUOTFEUOHS06zk0eZ8KFlp3UAAJX1qdWVB368=; b=Dq6BELwKWRDgL/3TBM1Xx7ojQMjcqrU6I8viwEGXaJZf0SJCeW/oTNC7z+UU0NE4RC 576cW/tXFdLbQdbrsudE4MjsIFqA0qtA2Tmi7YYnYlrlGrXTLBDoaI+oWKWHlXwa9brE slhrk1SKrVe79usx19e+STc+QIbQvSoJxMOvQBkfA5Tkf5uy8WthDdxTjxKyAscaehoZ 9fgrx1N8SPuFAAd0lOJqNXzbZmFI6Qe2+r5Ze4/ggvdo8MZWAOKddWG7fWf+ufNlZt75 cPrHyFLvUV8ZHaQW0baEGlkXhtkeTqS2cNDJ/4YpowgszVaD/SaCaQ/YAkVdRuHybgmx 91Bg== X-Gm-Message-State: ALoCoQmFvtF68AtpFxRm6BaTVeAiTPDf2i1HuYNYeAf3vNJPCHwRtoLtrXgmWXeIFrsj4LVT8eSj MIME-Version: 1.0 X-Received: by 10.107.138.28 with SMTP id m28mr3738977iod.24.1449056323218; Wed, 02 Dec 2015 03:38:43 -0800 (PST) Received: by 10.79.70.71 with HTTP; Wed, 2 Dec 2015 03:38:42 -0800 (PST) X-Originating-IP: [158.130.0.242] In-Reply-To: <3B906BDF-CA30-4EDF-ADA9-ABFC2A25014D@gmail.com> References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <3B906BDF-CA30-4EDF-ADA9-ABFC2A25014D@gmail.com> Date: Wed, 2 Dec 2015 11:38:42 +0000 Message-ID: From: Jacob Appelbaum To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 11:38:45 -0000 On 12/1/15, Yoav Nir wrote: > >> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum wrote: >> >> On 12/1/15, Viktor Dukhovni wrote: >>> On Mon, Nov 30, 2015 at 10:34:27AM +0000, Peter Gutmann wrote: >>> >>>> Bryan A Ford writes: >>>> >>>>> It would work just as well and in exactly the same way if the AEAD is >>>>> replaced with the traditional Encrypt-then-MAC construction, for >>>>> example. >>>> >>>> No it wouldn't, unless the encrypt part is a stream cipher. You're >>>> still >>>> locked into using an AEAD stream cipher or the equivalent of an AEAD >>>> stream >>>> cipher built with encrypt+MAC. It won't work with, for example, the >>>> OCB >>>> AEAD >>>> mode, or CBC + MAC. >>> >>> I think we should focus on what would get TLS 1.3 to be adopted: >>> >>> * Reasonably implementable in libraries that support older >>> versions alongside TLS 1.3. >>> >> >> That doesn't change with Bryan's suggestion, I think. >> >>> * Interoperable in the field with various capital-intensive >>> middle boxen. >> >> Which would those be? And what is the definition of capital-intensive >> for those watching on the sidelines? > > Firewall, IPS/IDS devices. Boxes that attempt to perform sanity-check on > protocols to make sure that the stuff going over TCP port 443 is really > HTTPS rather than an attempt at tunneling. There are some attacks such t= he > the code that protects against them needs to follow TLS record sizes. For > the most part these are not-so-interesting attacks, causing certain versi= ons > of certain browsers to hang, and they are expensive for the firewall to > protect against, so for the most part these protections are turned off. B= ut > it=E2=80=99s not everywhere. Could you be more specific? Which devices are we saying will break? Do you have model numbers? Are those vendors on this list? Do they agree that this will break and do we agree that they are a relevant stakeholder who has a user's security in mind? For example, do we really care what sandvine or xkeyscore or narus or similar vendors think? I think the answer is no. They're still going to do extremely powerful traffic analysis and the more information TLS leaks, the more they will use it to degrade the security of TLS for all users. It may be that they will be full, on path, attackers and yes, in some cases, they can do different more powerful attacks. Again, we should treat that as a negative thing and make it as hard as is possible. > > If enough middleboxes block TLS 1.3, the browsers will implement a downgr= ade > dance. If they do that, attackers will be able to exploit the downgrade > dance. I don=E2=80=99t think the net effect is better security. We=E2=80= =99d be far better > off writing a separate document on how to use the padding feature that is > already in 1.3 to mitigate traffic analysis without actually flooding you= r > Internet connection. Splitting records and padding a few can be more > effective than masking the length bits. Censors are going to perform surveillance and then censor; TLS 1.3 should treat surveillance as a security issue and censorship as an attack. It may be that we can't stop certain kinds of on path attacks but man on the side seems nearly entirely do-able. I mean aside from the TCP reset issues do to layer violation concerns. At least we'll have DTLS, which won't suffer from such a trivial denial of service... right? All the best, Jacob From nobody Wed Dec 2 04:00:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B801A889D for ; Wed, 2 Dec 2015 03:59:59 -0800 (PST) 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 NGPGEMVdD4pb for ; Wed, 2 Dec 2015 03:59:57 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607691A8894 for ; Wed, 2 Dec 2015 03:59:57 -0800 (PST) Received: by wmww144 with SMTP id w144so211649372wmw.1 for ; Wed, 02 Dec 2015 03:59:56 -0800 (PST) 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=CPTmPDcrBKMCd8fREWN4w/GlOwD/OGBUWtaha2jsgBo=; b=FjuL7TeOKCBdVjXhY1haZs65q0Mkfxv6JKJQ8BgHjEZ8YvWFb7l6GguWSB121M1DZ8 tpR4yU6Kb+z7LBAZIPjCnZov/vGc73RJGu+trx7cYveZu9Gsg6D1U9rym0zzTib+KNJ4 L5xhgnZpLwi78sGiY6vsxm/r+oTJjj9pIeUreRySAvS4RZj8JqD+njYDCkuO7IJ6Z29r ZK92dRmU9oGxt8Q/D/EDPNYCdE0kzIx9D5y0HrO5MUllZ4bclDAH/P82Bpw8znI8NcDk J84MtjyFhGb/HnWxT1WSzJlNnZEpu7t4NTiQBxIetpZg9SOAjVlYpxxT0dSbuHEmfqb0 ngLA== X-Received: by 10.194.87.99 with SMTP id w3mr4264310wjz.76.1449057595956; Wed, 02 Dec 2015 03:59:55 -0800 (PST) Received: from [172.24.249.232] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id c194sm2888563wmd.13.2015.12.02.03.59.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Dec 2015 03:59:54 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: Date: Wed, 2 Dec 2015 13:59:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <3B906BDF-CA30-4EDF-ADA9-ABFC2A25014D@gmail.com> To: Jacob Appelbaum X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 11:59:59 -0000 > On 2 Dec 2015, at 1:38 PM, Jacob Appelbaum = wrote: >=20 > On 12/1/15, Yoav Nir wrote: >>=20 >>>=20 >>> Which would those be? And what is the definition of = capital-intensive >>> for those watching on the sidelines? >>=20 >> Firewall, IPS/IDS devices. Boxes that attempt to perform sanity-check = on >> protocols to make sure that the stuff going over TCP port 443 is = really >> HTTPS rather than an attempt at tunneling. There are some attacks = such the >> the code that protects against them needs to follow TLS record sizes. = For >> the most part these are not-so-interesting attacks, causing certain = versions >> of certain browsers to hang, and they are expensive for the firewall = to >> protect against, so for the most part these protections are turned = off. But >> it=E2=80=99s not everywhere. >=20 > Could you be more specific? Which devices are we saying will break? Do > you have model numbers? Are those vendors on this list? Do they agree > that this will break and do we agree that they are a relevant > stakeholder who has a user's security in mind? I am no expert on middleboxes. I know a little about those that my = employer (Check Point) makes. I only know a little, because I=E2=80=99m = on the VPN side of things, not the IDS/IPS/next generation firewall = side. These are corporate firewalls. When it comes to filtering HTTPS = connections, firewalls have three ways to classify the connection: 1. Look at the SYN and SYN-ACK packets. Make decisions by IP addresses. 2. #1, and additionally follow the stream looking for certain patterns. 3. Full =E2=80=9CTLS proxy=E2=80=9D. Each of these is =E2=80=9Cheavier=E2=80=9D in amount of resources that = it consumes and in the amount of breakage that it might introduce than = the one before it, so you only use a higher-numbered way if the = lower-numbered way does not give you the results you need. Specifically = for #2 which is the one we=E2=80=99re concerned about, there are very = few attacks that can be detected by #2 that cannot be detected by #1. I = asked someone who does work on these =E2=80=9Cprotections=E2=80=9D as we = call them, and she told me that only two or three protections require = following the stream that do not require proxying, and those were turned = off in the default and recommended profiles. So at least with a Check = Point firewall, mostly you would not get breakage if record lengths were = encrypted, but someone making a client or a server cannot assume that = all paths will be free from such inspection. Also, there are many = firewall vendors and one is installed in most corporate environments. So at least one vendor is listening in on this list, and I have a good = hunch that at least Cisco, Blue Coat and several others are on this list = as well. Whether they are relevant stakeholders or not is to me the same = question as whether the network administrator in a corporate environment = is a relevant stakeholder. We just make the middlebox that they deploy.=20= > For example, do we really care what sandvine or xkeyscore or narus or > similar vendors think? I think the answer is no. They're still going > to do extremely powerful traffic analysis and the more information TLS > leaks, the more they will use it to degrade the security of TLS for > all users. It may be that they will be full, on path, attackers and > yes, in some cases, they can do different more powerful attacks. > Again, we should treat that as a negative thing and make it as hard as > is possible. >=20 >>=20 >> If enough middleboxes block TLS 1.3, the browsers will implement a = downgrade >> dance. If they do that, attackers will be able to exploit the = downgrade >> dance. I don=E2=80=99t think the net effect is better security. = We=E2=80=99d be far better >> off writing a separate document on how to use the padding feature = that is >> already in 1.3 to mitigate traffic analysis without actually flooding = your >> Internet connection. Splitting records and padding a few can be more >> effective than masking the length bits. >=20 > Censors are going to perform surveillance and then censor; TLS 1.3 > should treat surveillance as a security issue and censorship as an > attack. It may be that we can't stop certain kinds of on path attacks > but man on the side seems nearly entirely do-able. I mean aside from > the TCP reset issues do to layer violation concerns. At least we'll > have DTLS, which won't suffer from such a trivial denial of service... > right? Or just use IPsec (I did say I=E2=80=99m no that side of the = building=E2=80=A6) Yoav From nobody Wed Dec 2 04:38:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4ABA1A8987 for ; Wed, 2 Dec 2015 04:38:56 -0800 (PST) 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] 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 dT-7i7QkU1W9 for ; Wed, 2 Dec 2015 04:38:55 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D75C1A8983 for ; Wed, 2 Dec 2015 04:38:55 -0800 (PST) Received: by ioir85 with SMTP id r85so43763804ioi.1 for ; Wed, 02 Dec 2015 04:38:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+5khkrDiJJTxjjfJCUGkpcn2Itxm6buxyoRxpha1UDQ=; b=HnXY9PC3XoPDUznffU88tHugKoH2UvSVjaFgMrAFmg5dqBYfo0oZEW21cyZRFblUMC 2eB7QNv5SOIbJVqhAQ9SxAmWb9f7qxMoTTMf4C6P4ejxy4PDns/k79Xvy6+yB5EnXFem NTWgnlZO3kSkM6xKZuQr71/NtancxLZvPeqorpNogAXPs+6wJvxrlWSU1ur/AZ8Au2PU RUF4rmD59A2laUOrTAtp62xgBEbiCkfvqx4zObGdf1Ye3Td0ih7F2zR+b7hwGyAajDWI fC0Iup6DqwJJnB4/aaSMbOJGdBIbpfwTGI5PCW2+C3W0r6WSKFCpJnOax1X8cHjznPqi W8ZQ== 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=+5khkrDiJJTxjjfJCUGkpcn2Itxm6buxyoRxpha1UDQ=; b=eDQM0QLK6Njh71RvmhhejxNu0gNuhyhFnyNaYnUcpdpAU/k8uQ9c0uOgFvEcfKZ3Ky 0A0Cc+GVvJ5HoNGDgA9i0RUja/qgYv1TnfBX58pj9U9aY/XuiN7JbVTcFWA08Ko8gmYD dX5aoh57dItAc5lWQF8oesBk+B6dEinRBq2CKu7OJ8gQvfVtv3J39oNE2kEWacLggZd1 GenBi0t48s0uCU30sRaew4pCrpzHqPruvtUl2gog8IZVJs+8QxGItsCXRHH0mzyUSL5j rNYqUAUIZlBm2SXhGIt/tocF4IoAQmi++z/aE+qGNHtD1mN57XIbqJBcrBmH7jEclw2U e7Pw== X-Gm-Message-State: ALoCoQkdVAkg0uLvThlUNVpan21WGIIbvWwxQqLHtX16cPan/Pj7xdV/h8n3r6+q6PFL5tQOAp8O MIME-Version: 1.0 X-Received: by 10.107.138.28 with SMTP id m28mr4005094iod.24.1449059934711; Wed, 02 Dec 2015 04:38:54 -0800 (PST) Received: by 10.79.70.71 with HTTP; Wed, 2 Dec 2015 04:38:54 -0800 (PST) X-Originating-IP: [195.154.216.143] In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B95D5F@uxcn10-5.UoA.auckland.ac.nz> References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4B95D5F@uxcn10-5.UoA.auckland.ac.nz> Date: Wed, 2 Dec 2015 12:38:54 +0000 Message-ID: From: Jacob Appelbaum To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 12:38:56 -0000 On 12/2/15, Peter Gutmann wrote: > Jacob Appelbaum writes: > >>I think the only thing that comes close is when I've named a classified US >>government surveillance program (XKeyscore) that would probably have >> trouble >>with it. > > Why would XKeyscore have trouble with it? My point was that we're hearing a lot of concern trolling for vendors and the only "vendor" that has been explicitly named is XKeyscore: a "vendor" that is without a doubt one that we want to protect against. > Standard off-the-shelf routers, > not > even specialised USG surveillance gear, does fairly sophisticated flow > tracing, packet reassembly, connection analysis, and so on. It's built into > the router. Absolutely and this proposal will do nothing to change that for on path TLS 1.3 with TCP and probably for TLS 1.3 DTLS. > Encrypting the headers is, at best, a minor speedbump to > attackers (while being a major headache for implementers, particularly SSH's > way of doing it), because they can use the native capabilities of the > routing > hardware to sidestep the need to decrypt headers. If they are only a partial observer, I think Bryan's suggestion changes the game for TLS and DTLS to leak less information. If they are a full on path observer, they will have the full leaks of information made possible from TCP. Thus when composed with an anonymizing service, we'll find that these changes contribute to a full solution. > > If people really want to address this then they need to do the following: > > 1. Define a threat model. What are we supposed to be defending against? > > (Note: The Inside-Out Threat Model, "this is the defence, anything that > it > prevents is what we're defending against", is not a threat model). > > 2. List the various measures that can be used to defend against the threat: > Fixed-size packets, padding, quantised packet timing, etc. > > 3. Decide on which ones are necessary to defend against an actual threat, > and > which ones aren't, taking into account cost/benefit tradeoffs (is the > effort/overhead involved worth the gain?). > > 4. Provide guidance for TLS and SSH developers on how they can implement > these. A global passive adversary with a partial view is already harmed by the changes that have been proposed. A global active adversary with a partial view would be stymied too. Bryan has already said it in the thread and replied but I'll agree with him: we've done it and you're seemingly ignoring it. Furthermore some people are concerned about surveillance vendors that are not *opt-in* by the user - rather than treating that concern as abstract, I'd like to see what specific vendors we should help to weaken the security properties of TLS 1.3. > > Once that's done (and in particular #1 and #2), we have a framework within > which we can decide whether encrypting lengths is worth the annoyance it > creates for implementers. > I think this is better left in the part of the thread where Bryan responded - so I'll follow up there next. > Without this, the debate over encrypted lengths is, to quote Linus, nothing > more than "people wanking around with their opinions" (and yeah, that > includes > me). It is not an opinion that TLS is a metadata leaking protocol and it is seems that Bryan has found a way to reduce that leakage. With DTLS and UDP - a surveillance vendor will have very little metadata comparatively once Bryan's solution is part of the spec. All the best, Jacob From nobody Wed Dec 2 04:59:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAB01A89F6 for ; Wed, 2 Dec 2015 04:59:16 -0800 (PST) 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] 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 MGzDrggHPyiO for ; Wed, 2 Dec 2015 04:59:13 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0BD1A89FA for ; Wed, 2 Dec 2015 04:59:13 -0800 (PST) Received: by igcmv3 with SMTP id mv3so116865258igc.0 for ; Wed, 02 Dec 2015 04:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6X9/9pOqrZ4umLOLQtHP/+p5URQETdzn5tNiokJfmAU=; b=GCXP0S+c5INQScclnLr6K7O5yd0aVDWuGcRCRsC6EakTn4h6E57abuQDiT0ecWtWW3 SGEcgFmeAkA3zZL8jX8Xis87cgb/ljUTtmOeUrA1mNFkdKBF6z+Vl0VWEz4xzwzlBYpd qlzxOV7vahxqmlkL/a2p0lmOYeYfy18SSM8ahVQS66Nxi8fIBZtVghs60/W8lGuvq7iR U/i+uSv2bwbo+LOEFVJHM7dmHPuyiDfz05pLXtS2UQfkIU25h/AdYdUHDyKduTEmwM56 YP9CSb1qWzVV2tp1z+wxnhStQ5UuTlh2gW5pXsc4uqTIAyllSe1gI85m+qEjGnofO6Qf x9yA== 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=6X9/9pOqrZ4umLOLQtHP/+p5URQETdzn5tNiokJfmAU=; b=mrokmttPLLWE9pEjf86pSt6bW3V1NLyulKl7zn/UtVyvmYoryGqV3EZF7fPg3n7/tl X51l8B/rCaw0V6BMxFhmqxD+4grpXYrRtID9NX2AqREs4fJW1SDnQLG6CMaD8lCm9T0/ /j8zskBJFboQl8YLs19qPLpOdvVlcbceCVM8nU6bVKbzA7gkKuAVdNOSecuDdbtUcd90 fR/PaBwBh1azqVLS7VPNN8Yw5/dEI5w32zxkmGdJG9JTL6XDLvmIED23I0ux8ey1twng ow/tOSHRLJM2PsZKOcb4BHmO78Fq2PKaTNtcsNJff2rvIimZqudovz0/pLtWS7nKgQPg HDZQ== X-Gm-Message-State: ALoCoQlabbl2m6cmro2v3oaEEZX29oowxohbMALaAolQjfew6zdaY1K/hd+9IcYNuAsKb4DvGnfg MIME-Version: 1.0 X-Received: by 10.50.143.12 with SMTP id sa12mr1062843igb.82.1449061152926; Wed, 02 Dec 2015 04:59:12 -0800 (PST) Received: by 10.79.70.71 with HTTP; Wed, 2 Dec 2015 04:59:12 -0800 (PST) X-Originating-IP: [5.39.79.8] In-Reply-To: References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <3B906BDF-CA30-4EDF-ADA9-ABFC2A25014D@gmail.com> Date: Wed, 2 Dec 2015 12:59:12 +0000 Message-ID: From: Jacob Appelbaum To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 12:59:16 -0000 On 12/2/15, Yoav Nir wrote: > >> On 2 Dec 2015, at 1:38 PM, Jacob Appelbaum wrote: >> >> On 12/1/15, Yoav Nir wrote: >>> >>>> >>>> Which would those be? And what is the definition of capital-intensive >>>> for those watching on the sidelines? >>> >>> Firewall, IPS/IDS devices. Boxes that attempt to perform sanity-check o= n >>> protocols to make sure that the stuff going over TCP port 443 is really >>> HTTPS rather than an attempt at tunneling. There are some attacks such >>> the >>> the code that protects against them needs to follow TLS record sizes. >>> For >>> the most part these are not-so-interesting attacks, causing certain >>> versions >>> of certain browsers to hang, and they are expensive for the firewall to >>> protect against, so for the most part these protections are turned off. >>> But >>> it=E2=80=99s not everywhere. >> >> Could you be more specific? Which devices are we saying will break? Do >> you have model numbers? Are those vendors on this list? Do they agree >> that this will break and do we agree that they are a relevant >> stakeholder who has a user's security in mind? > > I am no expert on middleboxes. I know a little about those that my employ= er > (Check Point) makes. I only know a little, because I=E2=80=99m on the VPN= side of > things, not the IDS/IPS/next generation firewall side. I don't think we should worry about breaking poor little Check Point's traffic analysis devices. Allow me to shift the overton window: their device is a problem and we should treat it as a problem on the network. TLS should mitigate as many of the advantages that they use to harm end users. We should make those devices use as much RAM and as much disk space and as much CPU time as possible. In the words of a Google engineer who discovered the NSA had been doing traffic analysis on his backbone... > These are corporate > firewalls. When it comes to filtering HTTPS connections, firewalls have > three ways to classify the connection: > 1. Look at the SYN and SYN-ACK packets. Make decisions by IP addresses. > 2. #1, and additionally follow the stream looking for certain patterns. > 3. Full =E2=80=9CTLS proxy=E2=80=9D. > > > Each of these is =E2=80=9Cheavier=E2=80=9D in amount of resources that it= consumes and in > the amount of breakage that it might introduce than the one before it, so > you only use a higher-numbered way if the lower-numbered way does not giv= e > you the results you need. Specifically for #2 which is the one we=E2=80= =99re > concerned about, there are very few attacks that can be detected by #2 th= at > cannot be detected by #1. I asked someone who does work on these > =E2=80=9Cprotections=E2=80=9D as we call them, and she told me that only = two or three > protections require following the stream that do not require proxying, an= d > those were turned off in the default and recommended profiles. So at leas= t > with a Check Point firewall, mostly you would not get breakage if record > lengths were encrypted, but someone making a client or a server cannot > assume that all paths will be free from such inspection. Also, there are > many firewall vendors and one is installed in most corporate environments= . That sounds like you're saying that the vendor you represent won't have issues and that it isn't a problem. Unless I misunderstand, you're claiming a concern and you've just cleared up that concern. So we can move on with Bryan's proposal? > So at least one vendor is listening in on this list, and I have a good hu= nch > that at least Cisco, Blue Coat and several others are on this list as wel= l. I'd love for Blue Coat to step up and talk about how this is similarly not a problem or how it is a problem for their illegal surveillance business in Syria, where they've been caught selling surveillance and censorship gear. I suspect they won't say much but we can hope, right? > Whether they are relevant stakeholders or not is to me the same question = as > whether the network administrator in a corporate environment is a relevan= t > stakeholder. We just make the middlebox that they deploy. That is a kind of goal post shifting but seeminly weirdly not relevant, if I understand. If it won't trouble the middle box, it doesn't sound like the network administrator will have troubles. It will however reduce off-path reassembly to technique #1 from above and #2 will be partially eliminated and #3 isn't an option for that attacker anyway. We are working on solutions to #1, TLS 1.3 should reduce and if possible, eliminate #2, and #3 is something that should require consent of the user in question. Without consent, TLS 1.3 should hard fail closed as a security measure. >> For example, do we really care what sandvine or xkeyscore or narus or >> similar vendors think? I think the answer is no. They're still going >> to do extremely powerful traffic analysis and the more information TLS >> leaks, the more they will use it to degrade the security of TLS for >> all users. It may be that they will be full, on path, attackers and >> yes, in some cases, they can do different more powerful attacks. >> Again, we should treat that as a negative thing and make it as hard as >> is possible. >> >>> >>> If enough middleboxes block TLS 1.3, the browsers will implement a >>> downgrade >>> dance. If they do that, attackers will be able to exploit the downgrade >>> dance. I don=E2=80=99t think the net effect is better security. We=E2= =80=99d be far >>> better >>> off writing a separate document on how to use the padding feature that >>> is >>> already in 1.3 to mitigate traffic analysis without actually flooding >>> your >>> Internet connection. Splitting records and padding a few can be more >>> effective than masking the length bits. >> >> Censors are going to perform surveillance and then censor; TLS 1.3 >> should treat surveillance as a security issue and censorship as an >> attack. It may be that we can't stop certain kinds of on path attacks >> but man on the side seems nearly entirely do-able. I mean aside from >> the TCP reset issues do to layer violation concerns. At least we'll >> have DTLS, which won't suffer from such a trivial denial of service... >> right? > > Or just use IPsec (I did say I=E2=80=99m no that side of the building=E2= =80=A6) How well will IPsec deal with such an adversary? I think it is instructive at all the ways that a protocol won't compose cleanly with something like Tor, as well as how many distingusihers exist for technique #2 above. It is very frustrating because yes, it would be nice if we could just use IPsec. That is however nearly a total lost cause with regard to surveillance and censorship issues. I once talked to a Narus vendor who made some amazing claims about traffic analysis on IPsec - I'll try to dig up some documents. All the best, Jacob From nobody Wed Dec 2 05:33:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A281A8AE3 for ; Wed, 2 Dec 2015 05:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-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 W_yHqsE7kMae for ; Wed, 2 Dec 2015 05:33:32 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3DAF1A8ADC for ; Wed, 2 Dec 2015 05:33:21 -0800 (PST) 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 (Postfix) with ESMTPS id 89A0AC0CC63A; Wed, 2 Dec 2015 13:33:21 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-114.brq.redhat.com [10.34.0.114]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB2DXJaK012884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Dec 2015 08:33:20 -0500 From: Hubert Kario To: tls@ietf.org Date: Wed, 02 Dec 2015 14:33:13 +0100 Message-ID: <2651779.FONMJx2ulk@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.6-201.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: References: <56586A2F.1070703@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6344905.mW9gWTePsI"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 13:33:34 -0000 --nextPart6344905.mW9gWTePsI Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 02 December 2015 12:59:12 Jacob Appelbaum wrote: > On 12/2/15, Yoav Nir wrote: > >> On 2 Dec 2015, at 1:38 PM, Jacob Appelbaum > >> wrote:>>=20 > >> On 12/1/15, Yoav Nir wrote: > >>>> Which would those be? And what is the definition of > >>>> capital-intensive > >>>> for those watching on the sidelines? > >>>=20 > >>> Firewall, IPS/IDS devices. Boxes that attempt to perform > >>> sanity-check on protocols to make sure that the stuff going over > >>> TCP port 443 is really HTTPS rather than an attempt at tunneling.= > >>> There are some attacks such the > >>> the code that protects against them needs to follow TLS record > >>> sizes. > >>> For > >>> the most part these are not-so-interesting attacks, causing > >>> certain > >>> versions > >>> of certain browsers to hang, and they are expensive for the > >>> firewall to protect against, so for the most part these > >>> protections are turned off. But > >>> it=E2=80=99s not everywhere. > >>=20 > >> Could you be more specific? Which devices are we saying will break= ? > >> Do you have model numbers? Are those vendors on this list? Do they= > >> agree that this will break and do we agree that they are a > >> relevant stakeholder who has a user's security in mind? > >=20 > > I am no expert on middleboxes. I know a little about those that my > > employer (Check Point) makes. I only know a little, because I=E2=80= =99m on > > the VPN side of things, not the IDS/IPS/next generation firewall > > side. >=20 > I don't think we should worry about breaking poor little Check Point'= s > traffic analysis devices. Allow me to shift the overton window: their= > device is a problem and we should treat it as a problem on the > network. TLS should mitigate as many of the advantages that they use > to harm end users. We should make those devices use as much RAM and > as much disk space and as much CPU time as possible. In the words of > a Google engineer who discovered the NSA had been doing traffic > analysis on his backbone... Problem is that users care for the cat macros and wedding pictures on=20= their social network of choice. If the old version of browser works or=20= an other browser works then it /obviously/ is the new browsers fault=20= that the connection fails so it's the /new/ browser that is broken. So the browser vendor implements out-of-protocol fallback to old=20 protocol version so that it continues to work. That's a Bad Thing. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart6344905.mW9gWTePsI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJWXvMZAAoJEJKo0bgB0vX1LegP/R9Q2P8l0pdd/RACDhxZzjin 8M/CmSb6dEHow4b/F6WwcFTj2G0x3jRZZYdSsuV4FBO16XUERt0+a6k/mw4NlXGh 9h8DZzNvC1kPX9wwEwyLJOUbj9lqVV1WhLukhTUJbPdhLzFDP/d58ewv24RhWYL9 fxhINkuEehcpbc0MMZurRAOYckrXsG4zFmfrEykguoJKM4Mzhp58ZyHcGI1cjUde IYuQvQoGU0RbEch6wlbYMpXQZtbiDJVzb4auf4fdub7+zSIEoj95tyVqayOGQ8jt eGuLvyFN9oJ5EnObE5T6geI9hQvqqx6MgxukB4n3P3C50qqbO3ao3Ohsq68oCCaO /r6HQJJL/I8HxzwyvXwfGTgCn0OrpIBCduo0Lp501LkpQMg7gzWEp2JNBj9aQqMS +9J0OqiPrEJzSSvVCydvElUvKEOY2JDj+lhm8UNVG51SWJ0isiJEZcJ/dvDAkxOH knt3cIhRHlA0JoRDnc4OKLnjc5pcGZ68hOtfZ5+L9cJnJR0givyX2h/zzgOZbMLJ KXsleDABSJDq+pfsH9vtldjdVQKdH/CUmDmuXBdShQeXqShhoBQDNCJmKucpOb7G KISgnst/KBFjdNLmBHocpvD8drqC7T3vUzN0lkdF3CsjOGV9Nj/L5ZxgvKkFD+yk AAzeWIG0KXQEHxN5jgRI =77G9 -----END PGP SIGNATURE----- --nextPart6344905.mW9gWTePsI-- From nobody Wed Dec 2 05:38:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E601A8AF4 for ; Wed, 2 Dec 2015 05:38:31 -0800 (PST) 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 z4SbS56rXRqF for ; Wed, 2 Dec 2015 05:38:29 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40DDE1A8AF3 for ; Wed, 2 Dec 2015 05:38:28 -0800 (PST) Received: by wmww144 with SMTP id w144so57222664wmw.0 for ; Wed, 02 Dec 2015 05:38:26 -0800 (PST) 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=tJRoKa7TKPzPw4PJESfJnuzcHeRg1WSAnsYju8jdthA=; b=hB720mR1oTNk3VWlX5OpKnA8FcIDk/Cy0St0V51bNniiRGZYRgiTTvDGHROOLVa5yY eyA1D7udUHxF7TTVQqFeS6UTeLRs4ZdGF9M9vcK6SyC9s0q26x+CdDbUo28R0AF8qcaO QUV0C2Kan38BmYVstxxnKsvE6JQxLDm6CCGKDXD0yCWiNcnXwrcL4DNrj70yv7aaDTvq PIgYewtgugvV+eWdqHL62qaW4YnLxd7KAOvbKrOCO5DiIiQK8kmDukzvKe0R5f7xeE3R qAzY0u0x8NypM2a3J5T45eofZx4e1QNs8xxzqh05kJTSvXwzeoy+G5VLKzjOiG5btWOA 5kXA== X-Received: by 10.28.227.198 with SMTP id a189mr43761185wmh.74.1449063506842; Wed, 02 Dec 2015 05:38:26 -0800 (PST) Received: from [172.24.249.232] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id n7sm3238035wmf.21.2015.12.02.05.38.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Dec 2015 05:38:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: Date: Wed, 2 Dec 2015 15:38:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <3B906BDF-CA30-4EDF-ADA9-ABFC2A25014D@gmail.com> To: Jacob Appelbaum X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 13:38:31 -0000 > On 2 Dec 2015, at 2:59 PM, Jacob Appelbaum = wrote: >=20 >=20 >> These are corporate >> firewalls. When it comes to filtering HTTPS connections, firewalls = have >> three ways to classify the connection: >> 1. Look at the SYN and SYN-ACK packets. Make decisions by IP = addresses. >> 2. #1, and additionally follow the stream looking for certain = patterns. >> 3. Full =E2=80=9CTLS proxy=E2=80=9D. >>=20 >>=20 >> Each of these is =E2=80=9Cheavier=E2=80=9D in amount of resources = that it consumes and in >> the amount of breakage that it might introduce than the one before = it, so >> you only use a higher-numbered way if the lower-numbered way does not = give >> you the results you need. Specifically for #2 which is the one = we=E2=80=99re >> concerned about, there are very few attacks that can be detected by = #2 that >> cannot be detected by #1. I asked someone who does work on these >> =E2=80=9Cprotections=E2=80=9D as we call them, and she told me that = only two or three >> protections require following the stream that do not require = proxying, and >> those were turned off in the default and recommended profiles. So at = least >> with a Check Point firewall, mostly you would not get breakage if = record >> lengths were encrypted, but someone making a client or a server = cannot >> assume that all paths will be free from such inspection. Also, there = are >> many firewall vendors and one is installed in most corporate = environments. >=20 > That sounds like you're saying that the vendor you represent won't > have issues and that it isn't a problem. Unless I misunderstand, > you're claiming a concern and you've just cleared up that concern. So > we can move on with Bryan's proposal? To be clear, I don=E2=80=99t represent anybody. If I did, I would have = to clear this mailing list message with a corporate lawyer and PR = department. I don=E2=80=99t think Bryan=E2=80=99s proposal will hurt the = capabilities of a Check Point firewall, and it will make life difficult = for me as a developer no more than it will make life difficult for = developers of OpenSSL, NSS, SChannel, or any of a dozen other TLS = implementations. I don=E2=80=99t know about the other IDS/IPS/Firewall = devices. >> So at least one vendor is listening in on this list, and I have a = good hunch >> that at least Cisco, Blue Coat and several others are on this list as = well. >=20 > I'd love for Blue Coat to step up and talk about how this is similarly > not a problem or how it is a problem for their illegal surveillance > business in Syria, where they've been caught selling surveillance and > censorship gear. I suspect they won't say much but we can hope, right? I suspect that the Blue Coat people on this list do not represent their = employer either. >> Whether they are relevant stakeholders or not is to me the same = question as >> whether the network administrator in a corporate environment is a = relevant >> stakeholder. We just make the middlebox that they deploy. >=20 > That is a kind of goal post shifting but seeminly weirdly not > relevant, if I understand. If it won't trouble the middle box, it > doesn't sound like the network administrator will have troubles. >=20 > It will however reduce off-path reassembly to technique #1 from above > and #2 will be partially eliminated and #3 isn't an option for that > attacker anyway. >=20 > We are working on solutions to #1, TLS 1.3 should reduce and if > possible, eliminate #2, and #3 is something that should require > consent of the user in question. Without consent, TLS 1.3 should hard > fail closed as a security measure. A TLS proxy requires user consent (or at least device administrator = consent) with TLS 1.2. TLS 1.3 does not change that. >>> For example, do we really care what sandvine or xkeyscore or narus = or >>> similar vendors think? I think the answer is no. They're still going >>> to do extremely powerful traffic analysis and the more information = TLS >>> leaks, the more they will use it to degrade the security of TLS for >>> all users. It may be that they will be full, on path, attackers and >>> yes, in some cases, they can do different more powerful attacks. >>> Again, we should treat that as a negative thing and make it as hard = as >>> is possible. >>>=20 >>>>=20 >>>> If enough middleboxes block TLS 1.3, the browsers will implement a >>>> downgrade >>>> dance. If they do that, attackers will be able to exploit the = downgrade >>>> dance. I don=E2=80=99t think the net effect is better security. = We=E2=80=99d be far >>>> better >>>> off writing a separate document on how to use the padding feature = that >>>> is >>>> already in 1.3 to mitigate traffic analysis without actually = flooding >>>> your >>>> Internet connection. Splitting records and padding a few can be = more >>>> effective than masking the length bits. >>>=20 >>> Censors are going to perform surveillance and then censor; TLS 1.3 >>> should treat surveillance as a security issue and censorship as an >>> attack. It may be that we can't stop certain kinds of on path = attacks >>> but man on the side seems nearly entirely do-able. I mean aside from >>> the TCP reset issues do to layer violation concerns. At least we'll >>> have DTLS, which won't suffer from such a trivial denial of = service... >>> right? >>=20 >> Or just use IPsec (I did say I=E2=80=99m no that side of the = building=E2=80=A6) >=20 > How well will IPsec deal with such an adversary? I think it is > instructive at all the ways that a protocol won't compose cleanly with > something like Tor, as well as how many distingusihers exist for > technique #2 above. It is very frustrating because yes, it would be > nice if we could just use IPsec. That is however nearly a total lost > cause with regard to surveillance and censorship issues. I once talked > to a Narus vendor who made some amazing claims about traffic analysis > on IPsec - I'll try to dig up some documents. IPsec has had a lightly-implemented TFC feature since RFC 4301. Without = it a packet of IPsec is the same size as the original plaintext packet + = a constant overhead rounded up to 4 bytes. So you could do as much = traffic analysis on non-TFC IPsec as you could on the plaintext. Yoav From nobody Wed Dec 2 06:13:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47EE1A905B for ; Wed, 2 Dec 2015 06:13:28 -0800 (PST) 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, HTML_MESSAGE=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 GqOFZw8L3QO1 for ; Wed, 2 Dec 2015 06:13:24 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78421A906B for ; Wed, 2 Dec 2015 06:13:23 -0800 (PST) Received: by ykdv3 with SMTP id v3so47451896ykd.0 for ; Wed, 02 Dec 2015 06:13:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TIOIEk5M8Q1TCymIapJgWhEnPKqFdVHLTINvAj6jAv4=; b=vexBdqKuop4b4tV7E9o4iLHriUt4jsY63hfkHdMbI6Pn8f0q14h9DyaWez6IcvasPb Tky8bNMWlWJTHqz0ZFXkT8ZzkYQTICMjw/CLoMq+pTvfVKdtriRQ1k66EENRQ1RtwNff apy2+QH0/zaSB/L9TVvwBTKkmZu2RruAY2rGOA9ZKBB6TiuTEPKwf5NcJXQnpxZLagcb rL46PtuOSH623g+GnhY7uFaKzIfTbhT0gwq5RP6KInQz33LMb5Eek5nHa3ED49aYO4fF eaCR1fp3gkZpRRZrCWeDVz6fxoAMdgAGBFVXg73YQSPjDTKm+txcJ4VEEIUGHx+eetH1 V0ng== 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=TIOIEk5M8Q1TCymIapJgWhEnPKqFdVHLTINvAj6jAv4=; b=TOVwE1F9pr5HvVlY9rBWsNvxMU7CvR37GHU/DzuoHVclqdsMPnFkBRyys7eQfxQqRu 2t6E8+gE0oi41/Gd3qlHI+ceyzqsPm8hj2saEStQxB1MYvJxCeWIQZsC/rMZ+zIDwZkk s2T60NP/9NSVsOr66y0/6g5iAs4U1IixCaAGHcN4P+krV7qa4LrRJq/tIgSgz3GGlJNt xQEXucmaKuM1YbRcjiqdtJQgYwOU8dLAdBE6ah0GXEPEV3ZTaJHuBjudJj/8bFMaEkqX yybExW6N2s2GK863L4STinaKdwHrUoQkwvqRkkS5JyNwN/+1ht8WCpP1wAO+Bw3XHV3B CNjQ== X-Gm-Message-State: ALoCoQnDfE+xlMxmOCWErtu3Q6HcBsRU7vTTYjseg4LvzQzFaKZycyNOlQW3/JAZA4/NZkKHUmtX X-Received: by 10.13.218.198 with SMTP id c189mr2482864ywe.165.1449065603097; Wed, 02 Dec 2015 06:13:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Wed, 2 Dec 2015 06:12:43 -0800 (PST) In-Reply-To: References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <3B906BDF-CA30-4EDF-ADA9-ABFC2A25014D@gmail.com> From: Eric Rescorla Date: Wed, 2 Dec 2015 06:12:43 -0800 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=94eb2c08192a8799190525eae0ed Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 14:13:28 -0000 --94eb2c08192a8799190525eae0ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 2, 2015 at 5:38 AM, Yoav Nir wrote: > > I don=E2=80=99t think Bryan=E2=80=99s proposal will hurt the capabilities= of a Check Point > firewall, and it will make life difficult for me as a developer no more > than it will make life difficult for developers of OpenSSL, NSS, SChannel= , > or any of a dozen other TLS implementations. I don=E2=80=99t know about t= he other > IDS/IPS/Firewall devices. > The people who will be inconvenienced (if any) by changing the record framing in an externally visible way are not largely developers of middleboxes or stacks but rather (1) users and (2) client vendors and (3) server operators, who have to deal with connections being arbitrarily broken and/or damaged by inspection devices which expect to be able to observe packet framing. In Seattle, when the topic of stripping off the fixed three bytes of the record header came up (which would have had a similar impact), we agreed to defer it until we had measurements for the level of breakage that it would cause (an experiment which we at Mozilla are on the hook for). It seems to me tha= t this question should be handled similarly. -Ekr --94eb2c08192a8799190525eae0ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Dec 2, 2015 at 5:38 AM, Yoav Nir <ynir.ietf@gmail.com>= wrote:
I don=E2=80=99t think Bryan=E2=80=99s proposal will hurt the capabilities o= f a Check Point firewall, and it will make life difficult for me as a devel= oper no more than it will make life difficult for developers of OpenSSL, NS= S, SChannel, or any of a dozen other TLS implementations. I don=E2=80=99t k= now about the other IDS/IPS/Firewall devices.

The people who will be inconvenienced (if any) by changing the recor= d framing in an
externally visible way are not largely developers= of middleboxes or stacks but
rather (1) users and (2) client ven= dors and (3) server operators, who have to
deal with connections = being arbitrarily broken and/or damaged by inspection
devices whi= ch expect to be able to observe packet framing.

In= Seattle, when the topic of stripping off the fixed three bytes of the reco= rd
header came up (which would have had a similar impact), we agr= eed to defer
it until we had measurements for the level of breaka= ge that it would cause
(an experiment which we at Mozilla are on = the hook for). It seems to me that
this question should be handle= d similarly.

-Ekr




--94eb2c08192a8799190525eae0ed-- From nobody Wed Dec 2 06:37:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620BE1A90CC for ; Wed, 2 Dec 2015 06:37:16 -0800 (PST) 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, HTML_MESSAGE=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 EyZcbHzpCK3f for ; Wed, 2 Dec 2015 06:37:15 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4DDF1A909D for ; Wed, 2 Dec 2015 06:37:14 -0800 (PST) Received: by ykfs79 with SMTP id s79so48708564ykf.1 for ; Wed, 02 Dec 2015 06:37:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1QzIU8hXxv908FJyQxWcVZjTcrR77qJrTDBY4XnivsU=; b=1RGcGOLngn7F8gBXtbGr4eAJJ9C8Ut80zWcM2kT9se87sxJHI66K0Pg3OP9CMlZUtq Y9C1Ueh8yJF7R6ai7bjxKsI3hX8JvIoSuKEn7tBxKxR4i6EPwWoIuM2LyXmsNB09pfuE mv1XDyutcX3Wt9K2vYhJC8Hy7CYcmpv6jD+Cv6A56CKcGDwA0cfMdcsPfMe3k0oyZsml Z6CXpiW+VesQ+4WYYYn3W4lCCl9A9Cj0SNfmT2XJBfJCVUZplFF4vPePoZbu9TgU00Vr dAhrVyEScmUei6EZZBGT6Gzh7t81RTodesqpb7l2WR/067eBnUHuct6FAYTI4/D3ifDC bErw== 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=1QzIU8hXxv908FJyQxWcVZjTcrR77qJrTDBY4XnivsU=; b=DRWrETEBOvskdS8vlSXGyA4s8CzSw4MLtg2gHKNVxPQm8vzmTSpSrU538Yz+hnBAtl jKMrxK6Bljz9OwTQYSX2GZU3zLN96Drv9hvWeF/d3Fy96Pi4dlV0ROM3JRG+bJKv+31p ANNeSSKA+rNsfH1n7A/b/p4gFuEK5LLn7k2rHoLFPhq0tgKoLMStBprzDtZtcgQ54kth G0LppZx4luSdcnNwBBOxSX3nn82rqsfGloyjCEF/9DX0T/OtavcrvbRhUWpX9iXjDW/j 6KGC7j0YOk9eRq9n97btNHBajlU0bm5toMNsE85Qmc0GyMHbuOlXuDcGAW4vTIvEs9ll 3+eA== X-Gm-Message-State: ALoCoQngrEoYAxn99c2Qbu90w2bZpx9hfw4D5hg1gO4nM0HK8v4vWgapcHYZgfr+nsMGGoIgTUKB X-Received: by 10.13.236.10 with SMTP id v10mr2706115ywe.231.1449067034093; Wed, 02 Dec 2015 06:37:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Wed, 2 Dec 2015 06:36:34 -0800 (PST) In-Reply-To: <9BFA68AB-9677-4BE7-8F5E-D1A66EF95BA5@gmail.com> References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> <9BFA68AB-9677-4BE7-8F5E-D1A66EF95BA5@gmail.com> From: Eric Rescorla Date: Wed, 2 Dec 2015 06:36:34 -0800 Message-ID: To: Bryan Ford Content-Type: multipart/alternative; boundary=94eb2c0889dcd2d84c0525eb351c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 14:37:16 -0000 --94eb2c0889dcd2d84c0525eb351c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford wrote: > On 02 Dec 2015, at 06:02, Martin Thomson wrote= : > > On 1 December 2015 at 08:22, Bryan A Ford wrote= : > >> The 2-byte length field in each record's header no longer indicates > >> the length of the *current* record but instead indicates the length of > >> the *next* record. > > > > Ensuring that you know the length of the *next* record is difficult > > and could dramatically degrade latency, or adding extra bogus padding > > or extra bogus records. For instance, I can always send in bursts of > > two packets, a one octet packet that promises the remainder of the > > burst and one that promises a single octet packet. At that point, I > > get to do what I've always done and you have gained little other than > > an increase in packet size of around 19 octets (best case). > > That type of inefficiency is extremely easy to avoid; please read the res= t > of my proposal where I discussed exactly that at length. Yes, a > particularly stupid implementation could send everything in bursts of two > packets, but it=E2=80=99s ridiculously easy for a slightly smarter implem= entation > to avoid doing that. And what you=E2=80=99ve gained is complete encrypti= on and > integrity-checking of the whole TLS record before any part is interpreted= , > which seems like a nontrivial security improvement. It's not really clear to me what the anti-traffic-analysis benefit of your proposal is over and above just padding everything to a fixed size. That's certainly far easier for the implementation to do, especially in typical stacks where the application just calls SSL_Write (or whatever) and so there's no obvious API point to provide the "next length", so as a practical matter the stack will very often if not always be in "last block" mode. The primary security improvement of your proposal seems to be that an active attacker can't generate a packet header that will put the TLS implementation in a deadlock state where it's waiting for more data that will never come. This seems of modest value in TLS [0] given that the attacker can cause the connection to be torn down by modifying any packet. I agree, that this is not exactly the same as leaving the connection deadlocked but it still effectively breaks the connection. In addition, I'm not an expert on TCP internals, but can't you also cause a similar deadlock by removing a TCP segment sent to the receiver and then ACKing it to the sender so that there is a gap in the TCP stream? -Ekr [0] This issue doesn't apply to DTLS because the stack will just move onto the next UDP datagram. --94eb2c0889dcd2d84c0525eb351c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford <brynosaurus@gmail.com<= /a>> wrote:
On= 02 Dec 2015, at 06:02, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 1 December 2015 at 08:22, Bryan A Ford <brynosaurus@gmail.com> wrote:
>> The 2-byte length field in each record's header no longer indi= cates
>> the length of the *current* record but instead indicates the lengt= h of
>> the *next* record.
>
> Ensuring that you know the length of the *next* record is difficult > and could dramatically degrade latency, or adding extra bogus padding<= br> > or extra bogus records.=C2=A0 For instance, I can always send in burst= s of
> two packets, a one octet packet that promises the remainder of the
> burst and one that promises a single octet packet.=C2=A0 At that point= , I
> get to do what I've always done and you have gained little other t= han
> an increase in packet size of around 19 octets (best case).

That type of inefficiency is extremely easy to avoid; please read th= e rest of my proposal where I discussed exactly that at length.=C2=A0 Yes, = a particularly stupid implementation could send everything in bursts of two= packets, but it=E2=80=99s ridiculously easy for a slightly smarter impleme= ntation to avoid doing that.=C2=A0 And what you=E2=80=99ve gained is comple= te encryption and integrity-checking of the whole TLS record before any par= t is interpreted, which seems like a nontrivial security improvement.

It's not really clear to me what the anti-tr= affic-analysis benefit of your proposal
is over and above just pa= dding everything to a fixed size. That's certainly far
easier= for the implementation to do, especially in typical stacks where the
=
application just calls SSL_Write (or whatever) and so there's no o= bvious
API point to provide the "next length", so as a = practical matter the stack
will very often if not always be in &q= uot;last block" mode.

The primary security im= provement of your proposal seems to be that an
active attacker ca= n't generate a packet header that will put the TLS
implementa= tion in a deadlock state where it's waiting for more data that
will never come. This seems of modest value in TLS [0] given that the att= acker
can cause the connection to be torn down by modifying any p= acket.
I agree, that this is not exactly the same as leaving the = connection deadlocked
but it still effectively breaks the connect= ion. In addition, I'm not an expert on TCP internals, but can't you= also cause a similar deadlock by removing a TCP segment sent to the receiv= er and then ACKing it to the sender so that there is a gap in the TCP strea= m?

-Ekr

[0] This issu= e doesn't apply to DTLS because the stack will just move onto
the next UDP datagram.


--94eb2c0889dcd2d84c0525eb351c-- From nobody Wed Dec 2 07:15:12 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D792B1A00AC for ; Wed, 2 Dec 2015 07:15:10 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 N4vW8vIXYNPt for ; Wed, 2 Dec 2015 07:15:09 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B771A00C2 for ; Wed, 2 Dec 2015 07:15:09 -0800 (PST) Received: by wmec201 with SMTP id c201so258103283wme.0 for ; Wed, 02 Dec 2015 07:15:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamsap-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=usA1HGA3YumkjNBaYPVI8rwChgyYfrULLv5kMKjvWY8=; b=IRhiqW2DeBYIN0ext71R3R7u2nzWwQYnjKKakldWK6kTsTTzFzZNIDwQ3GaSaJJo1t HbzXQrKWFEYha8ICbUw6OO1qDf1cSAcRG+BeE1wKQ32GOea3lF499iakcnt8uWqwC63z sxMu+L3bh1ZOwQvH4UlHQ1dX6yGy+2khyjD17SDILZNGljM7UNUVtovGjncrFfBDQMmC dc+amrHeCZS0qrR6+Ha7oEbtcAQVBDfOEcBxhXtGZRsPg3n8c1vlCZyhj5bSMGuyeZ9j g0a23Tlsgfr6FE1bICOpg1bhoE0tA9LYJJmQjWeKKL+fzVZiui4hwex67z6TdFn5m2Qm pu9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=usA1HGA3YumkjNBaYPVI8rwChgyYfrULLv5kMKjvWY8=; b=Ficn4bHrdLaA8EPNFVMgcJWIeeQjWjqSmFJTBCrEGKuRn/pI0HgSjdOyi63RtV74st j+2pyIUFDPwwCiniDryWC7LjbHSGbY19KcChypOjynLpH0M2mSEDK60/JAHpUg+PCxFI NruITe2OP2a7GTZ23doS0ED5QSMQxEaRvVnxh16YZkNhwphiPxSrMMcP3zNH0rKtwo0r FU1lzl2Bl06UpA7U0zVikhkF8t0tFn2pSEOQxs3Pq5sSTnmWj+HzIFjIv2cwFrborahD qfKC55pyaFgS0VBxu5eksrU1IAAuQ7t8QmZZnvi8PYCnk0PTk388LsPFvvgvm5y4mxXE w58A== X-Gm-Message-State: ALoCoQnEyj++IJC0tWxHPrqrzt3wFvbx5HlD1cu7bGRLOT6LSDPp62r6Rb1xMsgaTgOLXAsrQhQR X-Received: by 10.28.234.200 with SMTP id g69mr6320674wmi.97.1449069307592; Wed, 02 Dec 2015 07:15:07 -0800 (PST) Received: from [192.168.18.6] ([94.3.213.136]) by smtp.gmail.com with ESMTPSA id a186sm3627409wmh.4.2015.12.02.07.15.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Dec 2015 07:15:06 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Mike Copley In-Reply-To: Date: Wed, 2 Dec 2015 15:14:56 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <3B906BDF-CA30-4EDF-ADA9-ABFC2A25014D@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 15:15:11 -0000 On 2/12/2015, at 1:38 pm, Yoav Nir wrote: >=20 >> On 2 Dec 2015, at 2:59 PM, Jacob Appelbaum = wrote: >>=20 >>=20 >>> These are corporate >>> firewalls. When it comes to filtering HTTPS connections, firewalls = have >>> three ways to classify the connection: >>> 1. Look at the SYN and SYN-ACK packets. Make decisions by IP = addresses. >>> 2. #1, and additionally follow the stream looking for certain = patterns. >>> 3. Full =93TLS proxy=94. >=20 >>> Whether they are relevant stakeholders or not is to me the same = question as >>> whether the network administrator in a corporate environment is a = relevant >>> stakeholder. We just make the middlebox that they deploy. >>=20 >> That is a kind of goal post shifting but seeminly weirdly not >> relevant, if I understand. If it won't trouble the middle box, it >> doesn't sound like the network administrator will have troubles. >>=20 >> It will however reduce off-path reassembly to technique #1 from above >> and #2 will be partially eliminated and #3 isn't an option for that >> attacker anyway. >>=20 >> We are working on solutions to #1, TLS 1.3 should reduce and if >> possible, eliminate #2, and #3 is something that should require >> consent of the user in question. Without consent, TLS 1.3 should hard >> fail closed as a security measure. >=20 > A TLS proxy requires user consent (or at least device administrator = consent) with TLS 1.2. TLS 1.3 does not change that. With SNI it=92s possible to operate a transparent TLS proxy without the = users consent. The proxy only has visibility of the SNI hostname - no = user data (source: the company I work develops routers with such a = proxy). It=92s quite useful in hotspot/public wifi environments where = making policy decisions based on hostname is more than sufficient, and = explicit user configuration of proxy settings is a non-starter. As long = as the SNI data is still available in the clear, encrypting subsequent = headers won't impact the ability for our particular proxy to operate, as = it=92s just a generic TCP relay agent at that point. With all that being said, I think the concerns about length hiding are = better addressed through other means rather than header encryption. Not = sure if this is the right place to consider, but would DTLS 1.3(?) be = able to encrypt headers and still handle packet loss and re-ordering? If = DTLS needs cleartext headers, would it be better to advise one approach = for both protocols? Regards, Mike Copley= From nobody Wed Dec 2 07:34:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F6A1A8ACD for ; Wed, 2 Dec 2015 07:34:15 -0800 (PST) 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_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6] 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 spE5zYbvL9Qa for ; Wed, 2 Dec 2015 07:34:13 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773B31A8AB3 for ; Wed, 2 Dec 2015 07:34:13 -0800 (PST) Received: by iofh3 with SMTP id h3so49278541iof.3 for ; Wed, 02 Dec 2015 07:34:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EwtOeFt9Pd4V/DcayHXpEq9VbX6FRp0jXfDDXHX0dC4=; b=wYPm3JCIK6lVyCd7DjCqJC5rCAsm9VxvQ6rnkvlZcOuJBu9ik+faOWjUASBv2og0mW 6C4Jayc5Mb9Mg0Pm4m5XXbdXyZwjvzUU+7zDZfGRtmayy4hzVMhneL6pEqjcr/OaGuTn VcCX16A87V53CtcttRuV2pX9x6JtxQoo4i/XAJV0YWJ1VmvChjGq6ciP09G08qL5Ioqt aikT+JYeRLTg913S7F0KhvpweJcc1qMeut4zusr96YtU2A8zCPvGT9bTVAb8WEcfVqB9 W2w/BVN1nV/nba+nOW4cVdGqLm8v/VR8cWzNTrgU/cRlDMm0lEEwMakv4dzJSRJjDVy1 pPaw== 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=EwtOeFt9Pd4V/DcayHXpEq9VbX6FRp0jXfDDXHX0dC4=; b=HwBaIVzDKXm7tV+3FEV+goGqADot+AwDlxGumtRGUEMSoSl8zJM6+Ap63cBi7mQDrW 7/bA0o5eF9uu17vU2Z5xQHDoA4CIsBLmB2DsZlDOAv7LHEP87LqRiFdITmMkL48xpXeY QD6cbgpDz6X8zj5cnWyLJHpkKwJgBxpcWM0o5m9El/FhzxcwyMl047yH/giQARh7UHjJ FNNjk8pRaHb9oUOvdCPypI+xmD+KcqNZiCM+yN3CrKSX0LtSMR3FN/a1sYdd5AK0vHUV sefmHQQWimi11cN7Wn+Rnv7SUw4BvSciaN0efVJasdH8jjg5u8ttdhW6GnRO22S0ag+2 0/xw== X-Gm-Message-State: ALoCoQlXxCBQgQs4CMKmH5TAJ0smhJWSIoftNijJpdt8c1wm6W/mVKX2TDHNnGWS33QxJFhm2eXM MIME-Version: 1.0 X-Received: by 10.107.137.19 with SMTP id l19mr3692461iod.138.1449070452857; Wed, 02 Dec 2015 07:34:12 -0800 (PST) Received: by 10.79.70.71 with HTTP; Wed, 2 Dec 2015 07:34:12 -0800 (PST) X-Originating-IP: [109.163.234.4] In-Reply-To: References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> <9BFA68AB-9677-4BE7-8F5E-D1A66EF95BA5@gmail.com> Date: Wed, 2 Dec 2015 15:34:12 +0000 Message-ID: From: Jacob Appelbaum To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 15:34:15 -0000 On 12/2/15, Eric Rescorla wrote: > On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford wrote: > >> On 02 Dec 2015, at 06:02, Martin Thomson >> wrote: >> > On 1 December 2015 at 08:22, Bryan A Ford >> > wrote: >> >> The 2-byte length field in each record's header no longer indicates >> >> the length of the *current* record but instead indicates the length o= f >> >> the *next* record. >> > >> > Ensuring that you know the length of the *next* record is difficult >> > and could dramatically degrade latency, or adding extra bogus padding >> > or extra bogus records. For instance, I can always send in bursts of >> > two packets, a one octet packet that promises the remainder of the >> > burst and one that promises a single octet packet. At that point, I >> > get to do what I've always done and you have gained little other than >> > an increase in packet size of around 19 octets (best case). >> >> That type of inefficiency is extremely easy to avoid; please read the >> rest >> of my proposal where I discussed exactly that at length. Yes, a >> particularly stupid implementation could send everything in bursts of tw= o >> packets, but it=E2=80=99s ridiculously easy for a slightly smarter imple= mentation >> to avoid doing that. And what you=E2=80=99ve gained is complete encrypt= ion and >> integrity-checking of the whole TLS record before any part is >> interpreted, >> which seems like a nontrivial security improvement. > > > It's not really clear to me what the anti-traffic-analysis benefit of you= r > proposal > is over and above just padding everything to a fixed size. That's certain= ly > far > easier for the implementation to do, especially in typical stacks where t= he > application just calls SSL_Write (or whatever) and so there's no obvious > API point to provide the "next length", so as a practical matter the stac= k > will very often if not always be in "last block" mode. > I think that it eliminates all static distinguisher in the protocol for all data covered by the encryption. That is a fantastically wonderful benefit. > The primary security improvement of your proposal seems to be that an > active attacker can't generate a packet header that will put the TLS > implementation in a deadlock state where it's waiting for more data that > will never come. This seems of modest value in TLS [0] given that the > attacker > can cause the connection to be torn down by modifying any packet. > I agree, that this is not exactly the same as leaving the connection > deadlocked > but it still effectively breaks the connection. In addition, I'm not an > expert on TCP internals, but can't you also cause a similar deadlock by > removing a TCP segment sent to the receiver and then ACKing it to the > sender so that there is a gap in the TCP stream? Yes, any TLS connection may be broken by TCP's total lack of confidentiality, integrity or authenticity. It seems that normally this happens at setup by IP:port blocking or during later transmission of a selector/distinguisher that triggers an attack (TCP RST or others). There is good work in this area by David Stainton with his Honeybadger project - he actually classified and implemented most of these TCP attacks to help detect QUANTUMINSERT attacks in the wild: https://www.noisebridge.net/pipermail/noisebridge-discuss/2015-April/0462= 73.html > > -Ekr > > [0] This issue doesn't apply to DTLS because the stack will just move ont= o > the next UDP datagram. An off-path attacker can't do much with DTLS, if designed correctly. Especially if they only see some packets - they'd only get the UDP headers and then the rest should be uniformly distributed random data, no? An attacker could thus only interfere during setup - which if they're on path - we can't stop and expect; the PKI should (ha!) help with this issue. After that point, especially with devices that move or are otherwise multi-homed, would be able to spray encrypted packets out to the network with little other than the UDP headers for an attacker to use. Bryan's proposal makes things strictly better with regard to a network attacker - especially a partial view or off-path attacker who can only inject packets or who require a selector to trigger an attack. Effectively, an attacker will be forced to shut down the connection at setup time or to use the layer separation issues with TCP at any point. The key difference is that they will have the same information as they did at setup time, which again seems as a strict improvement over the current status quo. All the best, Jacob From nobody Wed Dec 2 07:38:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A788E1A9127 for ; Wed, 2 Dec 2015 07:38:55 -0800 (PST) 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] 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 vO3HrpfG9_CV for ; Wed, 2 Dec 2015 07:38:54 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A1AA1A90D0 for ; Wed, 2 Dec 2015 07:38:54 -0800 (PST) Received: by igl9 with SMTP id 9so112995362igl.0 for ; Wed, 02 Dec 2015 07:38:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=byZI68KNnKZkJ4B/lQ5kBtrpwW1jVmBcvN+dxWP8tB0=; b=O9pLSeKxi1JsxnC1SW/Mc2RruK8qcI+9MXHdJdGeFuFgTB43C4lcT7vIXuVdl6snLF GZ2alGs24EAQNcyO5PJsdBlS6qxf1NyIR+lXygMid7bSiaodDXRRzpyXNeJb1ZWpiGY4 jaIDBt7tGdWZVwiS7itKGQZDKmNfpw/VIrLCvqbXK3HeoxlznYfgV9j9GajjNoiQZiRq 87KudOK+18y3rHWdORTCGdR9wfaDgKLFM6a1Eb8W8FkrqSlIdm2zPbtKPn3H1KFc5fcQ BCU4U4hiFEHFELmGel0M6GnxxxzTTi9hcDIt2BfiMQlfbzekKDC6rgcnfsd2gxTBypf1 nGrA== 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=byZI68KNnKZkJ4B/lQ5kBtrpwW1jVmBcvN+dxWP8tB0=; b=bJ/xpmWXI2OGMfPgu3impO4tzY3cSCmLEdkSyt2iSNXfdLkgehf33BK1/qrg/Wu5iq 1qAcHuvgTsvEimRkcOvhUwf+HqqDUPI8HqrgPgIaWNzcaQwwI5VaXmV1B8onMLmlnqal o2S9P/22cNsZw9VLyUJ2G7ESA/eTLJsmWD7q04w0mLPVmQuUYsoBzHdsK1mmlFnbK2Hk e2cMfazw3ddM1h1c+COhpyxTkQI47rBUFJzk63dASR6tdUgz9AAAIn/6B3fcso3f2Ofl quy10Y9F7H2PG5Zlq1oFOX6WZYfkK6xmboGz78TQM+StbivGFVkF6w0PgGra2HJPHkzE Dfng== X-Gm-Message-State: ALoCoQl09PoC7N+yXhSynM0Ykv/p51+U5o18FI3PwOsVzZTlbDDE3+oYB3SAZ2wh7O/Yo6BaOmBK MIME-Version: 1.0 X-Received: by 10.50.155.73 with SMTP id vu9mr4438727igb.89.1449070733568; Wed, 02 Dec 2015 07:38:53 -0800 (PST) Received: by 10.79.70.71 with HTTP; Wed, 2 Dec 2015 07:38:53 -0800 (PST) X-Originating-IP: [208.12.64.252] In-Reply-To: References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <3B906BDF-CA30-4EDF-ADA9-ABFC2A25014D@gmail.com> Date: Wed, 2 Dec 2015 15:38:53 +0000 Message-ID: From: Jacob Appelbaum To: Mike Copley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 15:38:55 -0000 On 12/2/15, Mike Copley wrote: > > On 2/12/2015, at 1:38 pm, Yoav Nir wrote: > >> >>> On 2 Dec 2015, at 2:59 PM, Jacob Appelbaum wrote: >>> >>> >>>> These are corporate >>>> firewalls. When it comes to filtering HTTPS connections, firewalls hav= e >>>> three ways to classify the connection: >>>> 1. Look at the SYN and SYN-ACK packets. Make decisions by IP addresses= . >>>> 2. #1, and additionally follow the stream looking for certain patterns= . >>>> 3. Full =E2=80=9CTLS proxy=E2=80=9D. >> >>>> Whether they are relevant stakeholders or not is to me the same questi= on >>>> as >>>> whether the network administrator in a corporate environment is a >>>> relevant >>>> stakeholder. We just make the middlebox that they deploy. >>> >>> That is a kind of goal post shifting but seeminly weirdly not >>> relevant, if I understand. If it won't trouble the middle box, it >>> doesn't sound like the network administrator will have troubles. >>> >>> It will however reduce off-path reassembly to technique #1 from above >>> and #2 will be partially eliminated and #3 isn't an option for that >>> attacker anyway. >>> >>> We are working on solutions to #1, TLS 1.3 should reduce and if >>> possible, eliminate #2, and #3 is something that should require >>> consent of the user in question. Without consent, TLS 1.3 should hard >>> fail closed as a security measure. >> >> A TLS proxy requires user consent (or at least device administrator >> consent) with TLS 1.2. TLS 1.3 does not change that. > > With SNI it=E2=80=99s possible to operate a transparent TLS proxy without= the users > consent. The proxy only has visibility of the SNI hostname - no user data > (source: the company I work develops routers with such a proxy). Yes, we use that for a pluggable transport ( https://trac.torproject.org/projects/tor/wiki/doc/meek ) to bypass such proxies - connect to google.com, use http header to route to blocked.com, and so on. > It=E2=80=99s quite > useful in hotspot/public wifi environments where making policy decisions > based on hostname is more than sufficient, and explicit user configuratio= n > of proxy settings is a non-starter. That is an attack in my book and public hotspots that do MITM are also a problem that we need to solve. It is partially solved with WISPr XML, I think. Though everything in this space is awful because it breaks everything by default while a system thinks it is online. > As long as the SNI data is still > available in the clear, encrypting subsequent headers won't impact the > ability for our particular proxy to operate, as it=E2=80=99s just a gener= ic TCP > relay agent at that point. I hope that we'll hide the SNI data by default and I understand that a discussion about encrypted SNI is currently scheduled for some point in the future. > With all that being said, I think the concerns about length hiding are > better addressed through other means rather than header encryption. Not s= ure > if this is the right place to consider, but would DTLS 1.3(?) be able to > encrypt headers and still handle packet loss and re-ordering? If DTLS nee= ds > cleartext headers, would it be better to advise one approach for both > protocols? I'm pretty sure that encryption is the only way to "hide" the data we want to hide... All the best, Jacob From nobody Wed Dec 2 07:41:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9827E1A913D for ; Wed, 2 Dec 2015 07:40:56 -0800 (PST) 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] 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 ZXQtNmUVP4rV for ; Wed, 2 Dec 2015 07:40:53 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC351A9150 for ; Wed, 2 Dec 2015 07:40:53 -0800 (PST) Received: by igbxm8 with SMTP id xm8so34996245igb.1 for ; Wed, 02 Dec 2015 07:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Fb+VMpntdn2xMsvRTAFfp6p/MnsHL4o44Z80HTFRic0=; b=vrMYXig9q4DFx2Pv/d3MBFAtMbtpYUMZwG513FmfzvSr1ej7MUWEy0WkOFcuKA175D g7voXGrtARyakEoAKQkqVsbyKX3qFVOc68Kgq4Ifn8G4QzWUWrmZxI2etHx0WpMcFqfn 87HieM8UjWfdUmhZK9RW+9YYbybL7P5wwcJ+aO3piu5bESM0kyYX8/gHIQVCZJOiCOH5 3lgbZF2u0PPZskGICgxsEnKKQwSgIC0k1RyCsFhtVWP/tZo3fNhd5csRnlGgggHCp2e4 z6eaFWLWZXvaMl4niT3PgMCRV0uo/+MeBpbOAwOnVM7aA2BDBHvB+AD1ftQ916Fa9S3j 3ICQ== 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=Fb+VMpntdn2xMsvRTAFfp6p/MnsHL4o44Z80HTFRic0=; b=B2kiKEm0Ke4m6FBUVE3cAHg3gURCRF72oe/QrzsgiGyh8yN+MrKMsxenKLLkPkkRWU GroIiSW1vFwIGdXqh6n7ii3NHKwfkMupiX7S+DKXKBvZEanzhAcoCGKM5qt481pEQ/ie AvSjVh9dxEbMmzvRrf/vaFeV5Q/3a3twDxzK92T5bm72phWkqGtS6Xbzv3xSF2Z+MbCZ eCv3aztcyuS0B/64x2VjZIZv/IFSB5prEl0OKplIhZo7fRr6aa66suBS4R79NZzCEVdK h5mcYN5JlfslfopIYaaYTf1xCBd5fzfYMNivp3GYVhGlsQZeDDzDJchN6REbAdJXDMAw 57Aw== X-Gm-Message-State: ALoCoQkoLUWZ6NvNvjYLgfSXIhroAymp4Q25B1omcqfxdyFSQP/3GaXcyBOE8duqaf8EUiIC+3VE MIME-Version: 1.0 X-Received: by 10.50.59.242 with SMTP id c18mr7857655igr.82.1449070852828; Wed, 02 Dec 2015 07:40:52 -0800 (PST) Received: by 10.79.70.71 with HTTP; Wed, 2 Dec 2015 07:40:52 -0800 (PST) X-Originating-IP: [208.12.64.252] In-Reply-To: References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <3B906BDF-CA30-4EDF-ADA9-ABFC2A25014D@gmail.com> Date: Wed, 2 Dec 2015 15:40:52 +0000 Message-ID: From: Jacob Appelbaum To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 15:40:56 -0000 On 12/2/15, Eric Rescorla wrote: > On Wed, Dec 2, 2015 at 5:38 AM, Yoav Nir wrote: >> >> I don=E2=80=99t think Bryan=E2=80=99s proposal will hurt the capabilitie= s of a Check >> Point >> firewall, and it will make life difficult for me as a developer no more >> than it will make life difficult for developers of OpenSSL, NSS, >> SChannel, >> or any of a dozen other TLS implementations. I don=E2=80=99t know about = the other >> IDS/IPS/Firewall devices. >> > > The people who will be inconvenienced (if any) by changing the record > framing in an > externally visible way are not largely developers of middleboxes or stack= s > but > rather (1) users and (2) client vendors and (3) server operators, who hav= e > to > deal with connections being arbitrarily broken and/or damaged by inspecti= on > devices which expect to be able to observe packet framing. Those are also exactly the same parties that benefit from the changes. Other people who benefit are ISPs, who can't log data that encryption prevents them from seeing, and there are probably others too. > > In Seattle, when the topic of stripping off the fixed three bytes of the > record > header came up (which would have had a similar impact), we agreed to defe= r > it until we had measurements for the level of breakage that it would caus= e > (an experiment which we at Mozilla are on the hook for). It seems to me > that > this question should be handled similarly. How can it break something that doesn't yet exist and how can we measure that? o_0 Again, I'm surprised that no one is attacking the crypto design that Bryan offered... All the best, Jacob From nobody Wed Dec 2 07:45:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D667E1A92B0 for ; Wed, 2 Dec 2015 07:45:23 -0800 (PST) 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 A7IQeH2KLHqJ for ; Wed, 2 Dec 2015 07:45:22 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049E91A899A for ; Wed, 2 Dec 2015 07:45:21 -0800 (PST) Received: by ykdv3 with SMTP id v3so50985681ykd.0 for ; Wed, 02 Dec 2015 07:45:20 -0800 (PST) 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=o9owRjCm/xWWaEg9gXG3i2ZzmzN3xpYFARl/e6Kv054=; b=kWXDDTYiA/ylKHF9ArP5Yv2o4MCc4iIOMDXix6izBYItljrEw0TZ62MqbkgoG3gM9x BwLnSg8T6wnylHeLzBVnT/Ol3Q78/UPXphV6bTXsChXPW867qcyGjadFLuUkRy5U9EFY V32LaXiYLIdzPNwsus1DWt57OkcNK0Gg/Ehx7fnCRlaOWS/pK0vlbbxberXMH7XZ04vE aGPiFgBAagwnhuFJXgbAFZ3E9O+Bvgqb5teDlI2FkcAzaJwZS/NBuOeDVQrmFf8urQQn XZpOprnyV4J+xFRUFppJmwwAUkmjbnA+tBhJfm+EkP0+70Z3ld2xW/WhWd4WwZmn11vX ofVg== MIME-Version: 1.0 X-Received: by 10.129.104.215 with SMTP id d206mr2916584ywc.329.1449071120235; Wed, 02 Dec 2015 07:45:20 -0800 (PST) Received: by 10.129.148.131 with HTTP; Wed, 2 Dec 2015 07:45:20 -0800 (PST) In-Reply-To: References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> <9BFA68AB-9677-4BE7-8F5E-D1A66EF95BA5@gmail.com> Date: Wed, 2 Dec 2015 10:45:20 -0500 Message-ID: From: Watson Ladd To: Jacob Appelbaum Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 15:45:24 -0000 On Wed, Dec 2, 2015 at 10:34 AM, Jacob Appelbaum wrot= e: > On 12/2/15, Eric Rescorla wrote: >> On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford wrote= : >> >>> On 02 Dec 2015, at 06:02, Martin Thomson >>> wrote: >>> > On 1 December 2015 at 08:22, Bryan A Ford >>> > wrote: >>> >> The 2-byte length field in each record's header no longer indicates >>> >> the length of the *current* record but instead indicates the length = of >>> >> the *next* record. >>> > >>> > Ensuring that you know the length of the *next* record is difficult >>> > and could dramatically degrade latency, or adding extra bogus padding >>> > or extra bogus records. For instance, I can always send in bursts of >>> > two packets, a one octet packet that promises the remainder of the >>> > burst and one that promises a single octet packet. At that point, I >>> > get to do what I've always done and you have gained little other than >>> > an increase in packet size of around 19 octets (best case). >>> >>> That type of inefficiency is extremely easy to avoid; please read the >>> rest >>> of my proposal where I discussed exactly that at length. Yes, a >>> particularly stupid implementation could send everything in bursts of t= wo >>> packets, but it=E2=80=99s ridiculously easy for a slightly smarter impl= ementation >>> to avoid doing that. And what you=E2=80=99ve gained is complete encryp= tion and >>> integrity-checking of the whole TLS record before any part is >>> interpreted, >>> which seems like a nontrivial security improvement. >> >> >> It's not really clear to me what the anti-traffic-analysis benefit of yo= ur >> proposal >> is over and above just padding everything to a fixed size. That's certai= nly >> far >> easier for the implementation to do, especially in typical stacks where = the >> application just calls SSL_Write (or whatever) and so there's no obvious >> API point to provide the "next length", so as a practical matter the sta= ck >> will very often if not always be in "last block" mode. >> > > I think that it eliminates all static distinguisher in the protocol > for all data covered by the encryption. That is a fantastically > wonderful benefit. What's a "static distinguisher"? Padding solves this problem as well, but it also solves problems resulting from TCP segmentation down the stack, which header encryption doesn't. What does header encryption offer that padding does not? Sincerely, Watson --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Dec 2 07:46:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83261A6FFA for ; Wed, 2 Dec 2015 07:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 e3LYkaof-FWY for ; Wed, 2 Dec 2015 07:46:07 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4299A1A92B8 for ; Wed, 2 Dec 2015 07:46:04 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B5DDE433486; Wed, 2 Dec 2015 15:46:02 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A02AC433457; Wed, 2 Dec 2015 15:46:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1449071162; bh=NeYXhcOsU4I+8NMCHjJCqFvzCtogvQv790w0yhmnTwE=; l=330; h=From:To:CC:Date:References:In-Reply-To:From; b=yvoOvKu2uDmA5l9M0XFTuN8SIXcqeyLfIQnD34V3920hsz5Sf0UkQTNtr3/E7dQ0Q J8oj87pfBrvBAFTLlvT8X+KJiOSdXWzN6scuo2zS3KdNG3RllAD62nfXoztfQG5E7q +6a+77oV/8bULgjzdVUrZZWNy5KmpUWYC87I/Wlo= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 9D1B1205C; Wed, 2 Dec 2015 15:46:02 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 2 Dec 2015 07:46:02 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Wed, 2 Dec 2015 10:46:02 -0500 From: "Salz, Rich" To: Jacob Appelbaum , Eric Rescorla Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all? Thread-Index: AQHRKc4vwBJv/xDF6kerxoHYn7vyUZ6zDYQAgAEO5oCAAH2vgIAAG3yAgADwwYCAAAtCAIAAf4CAgAG7GgCAAAXqAIAAEJQAgAAK8QCAAAmZgIAAGKEA//+tXmA= Date: Wed, 2 Dec 2015 15:46:01 +0000 Message-ID: <861d2065dc7a4fb9a2dec2c5dda3c8aa@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <3B906BDF-CA30-4EDF-ADA9-ABFC2A25014D@gmail.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: [172.19.38.164] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 15:46:10 -0000 DQo+QWdhaW4sIEknbSBzdXJwcmlzZWQgdGhhdCBubyBvbmUgaXMgYXR0YWNraW5nIHRoZSBjcnlw dG8gZGVzaWduIHRoYXQgQnJ5YW4gb2ZmZXJlZC4uLg0KDQpUaGV5IGFyZS4gIFNlY3VyaXR5IGlz IGFib3V0IHRyYWRlLW9mZnMsIGFuZCB0aGUgcXVlc3Rpb25zIGhhdmUgYmVlbiBpZiB0aGUgYmVu ZWZpdCBpcyB3b3J0aCB0aGUgY29tcGxleGl0eS4gIFBlb3BsZSBhcmUgYXNzdW1pbmcgdGhhdCBp dCB3b3Jrcy4NCg== From nobody Wed Dec 2 08:08:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A459E1AD1F5 for ; Wed, 2 Dec 2015 08:08:42 -0800 (PST) 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 k7orp83aN7A3 for ; Wed, 2 Dec 2015 08:08:39 -0800 (PST) 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 A64311ACEF6 for ; Wed, 2 Dec 2015 08:08:39 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id EA1712A7DA; Wed, 2 Dec 2015 17:08:37 +0100 (CET) X-purgate-ID: 152705::1449072517-00006F99-3739E19E/0/0 X-purgate-size: 515 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 8AA90402F9; Wed, 2 Dec 2015 17:08:37 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 6016A1A39B; Wed, 2 Dec 2015 17:08:37 +0100 (CET) In-Reply-To: To: Jacob Appelbaum Date: Wed, 2 Dec 2015 17:08:37 +0100 (CET) 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: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? 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: Wed, 02 Dec 2015 16:08:42 -0000 Jacob Appelbaum wrote: > > I hope that we'll hide the SNI data by default and I understand that a > discussion about encrypted SNI is currently scheduled for some point > in the future. Hiding SNI data is completely silly security-wise, and any TLSv1.2 backwards-compatible ClientHello must include a plaintext visible SNI. So your client will have to know a-priori, out-of-band or be configured to TLSv1.3-only in order to avoid using a TLSv1.2-compatible ClientHello with cleartext SNI. -Martin From nobody Wed Dec 2 08:38:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1B11B2BC2 for ; Wed, 2 Dec 2015 08:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 YzGko1Q6Aodw for ; Wed, 2 Dec 2015 08:38:34 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B568E1B2BC9 for ; Wed, 2 Dec 2015 08:38:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 56F97BE3E; Wed, 2 Dec 2015 16:38:32 +0000 (GMT) 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 8MnX7sfh3kgD; Wed, 2 Dec 2015 16:38:32 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 80105BDD0; Wed, 2 Dec 2015 16:38:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449074312; bh=jSjhCm5YoaIfhR/vW83SykGA+KCRAPOE2RQjpEdtWAw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=FTp3MkURPoCu8Ml52FVoIrwgIGtwQIDVc7sWSAjyHUxfh06/ZsDvxmGrm+0xABBEf vuFiQmMshKdDUJFX01YMLEKVJB4R1y271tgzYhH5GZxLAJzk5yq/tFpTIpwFatePoT kkFh6OKfj/PfQWtQI6ErqU+geoNKvoBXsLQ19EzY= To: Jacob Appelbaum , Mike Copley References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <3B906BDF-CA30-4EDF-ADA9-ABFC2A25014D@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <565F1E87.4080903@cs.tcd.ie> Date: Wed, 2 Dec 2015 16:38:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 16:38:39 -0000 On 02/12/15 15:38, Jacob Appelbaum wrote: >> > It’s quite >> > useful in hotspot/public wifi environments where making policy decisions >> > based on hostname is more than sufficient, and explicit user configuration >> > of proxy settings is a non-starter. > That is an attack in my book and public hotspots that do MITM are also > a problem that we need to solve. It is partially solved with WISPr > XML, I think. Though everything in this space is awful because it > breaks everything by default while a system thinks it is online. > There's a WG in the process of being chartered about captive portals [1], not sure exactly what it'll end up producing, but that's a place to go if interested in this specific topic. Cheers, S. [1] https://datatracker.ietf.org/doc/charter-ietf-capport/ From nobody Wed Dec 2 09:08:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA1B1A1A25 for ; Wed, 2 Dec 2015 09:08:52 -0800 (PST) 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, J_CHICKENPOX_12=0.6, 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 0-tfS3qwO00o for ; Wed, 2 Dec 2015 09:08:49 -0800 (PST) Received: from filtteri1.pp.htv.fi (filtteri1.pp.htv.fi [213.243.153.184]) by ietfa.amsl.com (Postfix) with ESMTP id AB9B31A0367 for ; Wed, 2 Dec 2015 09:08:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri1.pp.htv.fi (Postfix) with ESMTP id 2183B21B804; Wed, 2 Dec 2015 19:08:48 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri1.pp.htv.fi [213.243.153.184]) (amavisd-new, port 10024) with ESMTP id O54olU5GpaJ1; Wed, 2 Dec 2015 19:08:48 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id EF8EA5BC002; Wed, 2 Dec 2015 19:08:47 +0200 (EET) Date: Wed, 2 Dec 2015 19:08:45 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20151202170845.GA25111@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151201185733.GB15222@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft status and updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 17:08:52 -0000 On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote: > > 3. The server provides g^y in his ServerHello and then g^xy and g^xs > are jointly used to produce the traffic keys and also to form a MAC over > the handshake. As Hugo pointed out originally, this alone should > be sufficient to authenticate the server's side of the connection and > you could omit the server CertificateVerify (Hugo, please correct > me if I have misunderstood). Is it guaranteed that the groups are the same? Even if it is, due to implementation bugs, bad idea to rely upon that. > Trying to read between the lines, is your concern that the server is > now no longer explicitly signing over the ServerConfiguration in > its CertificateVerify [Note that the client continues to do so]? The idea > behind removing that was to make the 1-RTT part of the handshake > more uniform regardless of whether 0-RTT data was used. > I'm certainly open to putting that back in if it's needed, but can you > explain your concern in more detail? The concern is that attacker that has managed to inject g^s for known s is able to impersonate the server even through server certificate validation on subsequent connections (under some conditions). (Indirectly) signing g^s would prevent this. ... Funkily enough, this attack doesn't work against either tls-unique nor tls-extractor (however, those still fail nonce check with respect to SS)... -Ilari From nobody Wed Dec 2 09:30:12 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4999C1ACAD5 for ; Wed, 2 Dec 2015 09:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] 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 qocRrJzAKaE7 for ; Wed, 2 Dec 2015 09:30:03 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5507F1AC419 for ; Wed, 2 Dec 2015 09:30:03 -0800 (PST) Received: by ykdr82 with SMTP id r82so54869922ykd.3 for ; Wed, 02 Dec 2015 09:30:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=idRe9Dsu5GK2tHqLdMUbmMNPD/PUOW2wavbU4zd4WUM=; b=05IFHpzkL8Cfqpa0Hn0LlMnxENxEjUHNuO7Vg1p9PyGqodh8EDrLkETodUDy3oA7o1 CSKXnZy68AvLevPfxT8WMqiIGGvlrMioK9UVM5UIECYQhq2oLqjNK4tmLD3svWrWtb/5 fDpM2F++Nkh7FctJqwVwGfe+olezbddszLyzeQEvsfcbs4HVTus+02of6ybscUrLiZq4 4xu4f9x4RQiYDj3bE5Sg+cg3MQypjYkUhSZIgWKApnN+YgqlKorkfiDDoAfZOb4sEOZ/ 1sJXM31I057XNP+gMzdCon50e6jB1ZY4nDzsm7OA1Sd0ZNHLC2lniLls2HJAWTmvQi2i z6Wg== 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=idRe9Dsu5GK2tHqLdMUbmMNPD/PUOW2wavbU4zd4WUM=; b=aFhyCIngl6fJiP65IMIOtfES/B/oJXaNkZXh6NLgIlyKzgej9C2fKWAh+iClYwy3aW 7hLQlUJPZCnAKNCmzOKl3MDQWnkB+UZABw74FXX4tft0tPZ/G/v4DSLKC71DnL2a1r0j ePrx3Sb5qgSVmHb0nYetXooedKECMAdCTSAJNstAxvlV5O4Tr5ekPipij6tBhLa0jgf3 7aJn6RTj1w+XNQUJ8BxDqd6xMuMPm3CvQuOY/MsfifAo4LINANMtLnNjw7tIrv+hJ2Hm ZeG1Re0zAWUDj1nzaz9bxAln+pNsC74TixCoPprBNGoI7T9aC6CPSS9a42pse/87SitA k+LQ== X-Gm-Message-State: ALoCoQlDIKZT6Vxy1g0n19WHJ+REgBLBmlwIPwuCUlZeoI4Yj1XrsD/SASxMkkvYK11vx1nHDk5N X-Received: by 10.129.34.4 with SMTP id i4mr3071227ywi.155.1449077402612; Wed, 02 Dec 2015 09:30:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Wed, 2 Dec 2015 09:29:23 -0800 (PST) In-Reply-To: <20151202170845.GA25111@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151201185733.GB15222@LK-Perkele-V2.elisa-laajakaista.fi> <20151202170845.GA25111@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Wed, 2 Dec 2015 09:29:23 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11408678d603950525ed9f1a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft status and updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 17:30:10 -0000 --001a11408678d603950525ed9f1a Content-Type: text/plain; charset=UTF-8 On Wed, Dec 2, 2015 at 9:08 AM, Ilari Liusvaara wrote: > On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote: > > > > 3. The server provides g^y in his ServerHello and then g^xy and g^xs > > are jointly used to produce the traffic keys and also to form a MAC over > > the handshake. As Hugo pointed out originally, this alone should > > be sufficient to authenticate the server's side of the connection and > > you could omit the server CertificateVerify (Hugo, please correct > > me if I have misunderstood). > > Is it guaranteed that the groups are the same? > Yes, it's a requirement that the groups be the same. If the text doesn't say that, it should. > Even if it is, due to implementation bugs, bad idea to rely upon that. Can you expand on this point? Is there a specific easy-to-make implementation error you are concerned with? > > > Trying to read between the lines, is your concern that the server is > > now no longer explicitly signing over the ServerConfiguration in > > its CertificateVerify [Note that the client continues to do so]? The idea > > behind removing that was to make the 1-RTT part of the handshake > > more uniform regardless of whether 0-RTT data was used. > > I'm certainly open to putting that back in if it's needed, but can you > > explain your concern in more detail? > > The concern is that attacker that has managed to inject g^s for > known s is able to impersonate the server even through server certificate > validation on subsequent connections (under some conditions). > I'm sorry, I'm still not following. All the data that the server sends is tied to g^y which is signed with the server's certificate, so even if s were published, the attacker should not be able to inject data which the client would accept. With that said, it's certainly true that if the attacker is able to convince the client that the server has a certain g^a where a is known to the attacker, then the client has a problem because he will encrypt data *to* the attacker in 0-RTT, so obviously we are assuming that the attacker does not know s and cannot convince the client to accept a g^s of his choice. (Indirectly) signing g^s would prevent this. > > ... Funkily enough, this attack doesn't work against either tls-unique > nor tls-extractor (however, those still fail nonce check with respect > to SS)... Do you think you could draw a ladder diagram that shows the attack you are concerned about? -Ekr > > > > -Ilari > --001a11408678d603950525ed9f1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 2, 2015 at 9:08 AM, Ilari Liusvaara <<= a href=3D"mailto:ilariliusvaara@welho.com" target=3D"_blank">ilariliusvaara= @welho.com> wrote:
On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote:
>
> 3. The server provides g^y in his ServerHello and then g^xy and g^xs > are jointly used to produce the traffic keys and also to form a MAC ov= er
> the handshake. As Hugo pointed out originally, this alone should
> be sufficient to authenticate the server's side of the connection = and
> you could omit the server CertificateVerify (Hugo, please correct
> me if I have misunderstood).

Is it guaranteed that the groups are the same?
=
Yes, it's a requirement that the groups be the same. If = the text doesn't
say that, it should.

=C2=A0
Even if it is, due to implementation bugs, bad idea to rely upon that.

Can you expand on this point? Is there a specif= ic easy-to-make implementation
error you are concerned with?

=C2=A0

> Trying to read between the lines, is your concern that the server is > now no longer explicitly signing over the ServerConfiguration in
> its CertificateVerify [Note that the client continues to do so]? The i= dea
> behind removing that was to make the 1-RTT part of the handshake
> more uniform regardless of whether 0-RTT data was used.
> I'm certainly open to putting that back in if it's needed, but= can you
> explain your concern in more detail?

The concern is that attacker that has managed to inject g^s for
known s is able to impersonate the server even through server certificate validation on subsequent connections (under some conditions).

I'm sorry, I'm still not following. All the = data that the server sends is tied to
g^y which is signed with th= e server's certificate, so even if s were published,
the atta= cker should not be able to inject data which the client would accept.
=

With that said, it's certainly true that if the att= acker is able to convince the
client that the server has a certai= n g^a where a is known to the attacker,
then the client has a pro= blem because he will encrypt data *to* the
attacker in 0-RTT, so = obviously we are assuming that the attacker does
not know s and c= annot convince the client to accept a g^s of his
choice.


(Indirectly) sign= ing g^s would prevent this.

... Funkily enough, this attack doesn't work against either tls-unique<= br> nor tls-extractor (however, those still fail nonce check with respect
to SS)...

Do you think you could draw a lad= der diagram that shows the attack you
are concerned about?
<= div>
-Ekr



<= div>
=C2=A0



-Ilari

--001a11408678d603950525ed9f1a-- From nobody Wed Dec 2 09:34:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59741ACC8F for ; Wed, 2 Dec 2015 09:34:19 -0800 (PST) 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, HTML_MESSAGE=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 veA8PVkaS7vc for ; Wed, 2 Dec 2015 09:34:18 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B001ACC87 for ; Wed, 2 Dec 2015 09:34:17 -0800 (PST) Received: by ykfs79 with SMTP id s79so55578167ykf.1 for ; Wed, 02 Dec 2015 09:34:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xywpkH4V2K9w01Uk11Gb+2I+Sd/aQyWPIAbvO2zKMAM=; b=Sbl4eARfi9TK/GAVzOC+m/tNFKofbjSx0oSYrjasL2DCKqOi/QFtZX9igjhPW2J7yS pry12sSwdXhJqOUfX6Q34RkJ18Ti5SxNRcM3x5BEVZtJ5gNzfA4+UAYn6AdrjN5FkdI9 o2VJxGGTw+4Lj/CzaohLLb7c1QeVx4PYUrtFutt3xYsm15ZZiB4XP00+XkJxHpMtkp3F i0P2qdfHm4+rxX7tBMS9Ii02lbaX4gK2T9GoyMMWrBAwtBylKpht+r9NjoXVXd3a4gaa JXR2xBIv33VV6QHxk6mpIVv7XZsnF3IG7bjrFrnAN6oLxiHEeJ171wCs8q58bKtqkOeP ZaJg== 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=xywpkH4V2K9w01Uk11Gb+2I+Sd/aQyWPIAbvO2zKMAM=; b=kVOqvHcsmJbCG+aIde4PO0YO7YOWrsvvv6M/ujXKdGE9VGZ9fxQB+4LpbxTp63hVKW 6oB3/WKXNTiPhGFyhSsWKehC0A5nEr1EGcvyMktzCbYO6CJnsVYcRjFGClpiMeAzcRl8 7WERMzu27pSFkS+7xPuTKbsK4nzWqfe4J0BZlgpH/Oy2E9gtYh/FPLhGM4ecpvKo54rc I+j9caNwWJ814BVXfOWIDQkulWNSszOYiJKi8EO3yAnQaH8dhDOt0OFKsQBOUPuLTjBG Npgvh5ozuXaiLHGrySw7NKQRDEYb+31DYgPIP9rEjUSbwXcvy6mSt8JVCDFt74kNEx+M a6LA== X-Gm-Message-State: ALoCoQlVYxDcwR1m/IlXKBaVUgp4bPHjmLkv1Wgaq1Dhk2rHLtCcddmERYwu60G9sQtJ5CfSJave X-Received: by 10.13.197.194 with SMTP id h185mr3124735ywd.12.1449077657208; Wed, 02 Dec 2015 09:34:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Wed, 2 Dec 2015 09:33:37 -0800 (PST) In-Reply-To: References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> <9BFA68AB-9677-4BE7-8F5E-D1A66EF95BA5@gmail.com> From: Eric Rescorla Date: Wed, 2 Dec 2015 09:33:37 -0800 Message-ID: To: Jacob Appelbaum Content-Type: multipart/alternative; boundary=001a114edd4a02c1d10525edaf56 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 17:34:19 -0000 --001a114edd4a02c1d10525edaf56 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 2, 2015 at 7:34 AM, Jacob Appelbaum wrote= : > On 12/2/15, Eric Rescorla wrote: > > On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford > wrote: > > > >> On 02 Dec 2015, at 06:02, Martin Thomson > >> wrote: > >> > On 1 December 2015 at 08:22, Bryan A Ford > >> > wrote: > >> >> The 2-byte length field in each record's header no longer indicates > >> >> the length of the *current* record but instead indicates the length > of > >> >> the *next* record. > >> > > >> > Ensuring that you know the length of the *next* record is difficult > >> > and could dramatically degrade latency, or adding extra bogus paddin= g > >> > or extra bogus records. For instance, I can always send in bursts o= f > >> > two packets, a one octet packet that promises the remainder of the > >> > burst and one that promises a single octet packet. At that point, I > >> > get to do what I've always done and you have gained little other tha= n > >> > an increase in packet size of around 19 octets (best case). > >> > >> That type of inefficiency is extremely easy to avoid; please read the > >> rest > >> of my proposal where I discussed exactly that at length. Yes, a > >> particularly stupid implementation could send everything in bursts of > two > >> packets, but it=E2=80=99s ridiculously easy for a slightly smarter > implementation > >> to avoid doing that. And what you=E2=80=99ve gained is complete encry= ption and > >> integrity-checking of the whole TLS record before any part is > >> interpreted, > >> which seems like a nontrivial security improvement. > > > > > > It's not really clear to me what the anti-traffic-analysis benefit of > your > > proposal > > is over and above just padding everything to a fixed size. That's > certainly > > far > > easier for the implementation to do, especially in typical stacks where > the > > application just calls SSL_Write (or whatever) and so there's no obviou= s > > API point to provide the "next length", so as a practical matter the > stack > > will very often if not always be in "last block" mode. > > > > I think that it eliminates all static distinguisher in the protocol > for all data covered by the encryption. That is a fantastically > wonderful benefit. Wouldn't that benefit be equally achieved by simply padding all records to a fixed length? You could do this with no protocol change and, as I said, it's far easier for the implementation. > -Ekr > > > > [0] This issue doesn't apply to DTLS because the stack will just move > onto > > the next UDP datagram. > > An off-path attacker can't do much with DTLS, if designed correctly. > Especially if they only see some packets - they'd only get the UDP > headers and then the rest should be uniformly distributed random data, > no? DTLS records do in fact contain a length field because it's possible to pack >1 record into a single UDP datagram. In practice, I think that most stacks do 1:1 except perhaps during the handshake. They also contain a sequence number to aid in reconstruction (important in this case because TLS 1.3 uses the sequence number to form the AEAD nonce). However, as you suggest, an attacker can't DoS DTLS connections by injecting a small number of packets because the DTLS stack will just reject bogus packets. -Ekr --001a114edd4a02c1d10525edaf56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 2, 2015 at 7:34 AM, Jacob Appelbaum <<= a href=3D"mailto:jacob@appelbaum.net" target=3D"_blank">jacob@appelbaum.net= > wrote:
On 12/2/15, Eric Rescorla <ekr@rtfm.com> wrote:
> On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford <brynosaurus@gmail.com> wrote:
>
>> On 02 Dec 2015, at 06:02, Martin Thomson <martin.thomson@gmail.com>
>> wrote:
>> > On 1 December 2015 at 08:22, Bryan A Ford <brynosaurus@gmail.com>
>> > wrote:
>> >> The 2-byte length field in each record's header no lo= nger indicates
>> >> the length of the *current* record but instead indicates = the length of
>> >> the *next* record.
>> >
>> > Ensuring that you know the length of the *next* record is dif= ficult
>> > and could dramatically degrade latency, or adding extra bogus= padding
>> > or extra bogus records.=C2=A0 For instance, I can always send= in bursts of
>> > two packets, a one octet packet that promises the remainder o= f the
>> > burst and one that promises a single octet packet.=C2=A0 At t= hat point, I
>> > get to do what I've always done and you have gained littl= e other than
>> > an increase in packet size of around 19 octets (best case). >>
>> That type of inefficiency is extremely easy to avoid; please read = the
>> rest
>> of my proposal where I discussed exactly that at length.=C2=A0 Yes= , a
>> particularly stupid implementation could send everything in bursts= of two
>> packets, but it=E2=80=99s ridiculously easy for a slightly smarter= implementation
>> to avoid doing that.=C2=A0 And what you=E2=80=99ve gained is compl= ete encryption and
>> integrity-checking of the whole TLS record before any part is
>> interpreted,
>> which seems like a nontrivial security improvement.
>
>
> It's not really clear to me what the anti-traffic-analysis benefit= of your
> proposal
> is over and above just padding everything to a fixed size. That's = certainly
> far
> easier for the implementation to do, especially in typical stacks wher= e the
> application just calls SSL_Write (or whatever) and so there's no o= bvious
> API point to provide the "next length", so as a practical ma= tter the stack
> will very often if not always be in "last block" mode.
>

I think that it eliminates all static distinguisher in the prot= ocol
for all data covered by the encryption. That is a fantastically
wonderful benefit.

Wouldn't that benefi= t be equally achieved by simply padding all records
to a fixed le= ngth? You could do this with no protocol change and, as I
said, i= t's far easier for the implementation.=C2=A0

<= br>
> -Ekr
>
> [0] This issue doesn't apply to DTLS because the stack will just m= ove onto
> the next UDP datagram.

An off-path attacker can't do much with DTLS, if designed correc= tly.
Especially if they only see some packets - they'd only get the UDP
headers and then the rest should be uniformly distributed random data,
no?

DTLS records do in fact contain a leng= th field because it's possible to
pack >1 record into a si= ngle UDP datagram. In practice, I think that
most stacks do 1:1 e= xcept perhaps during the handshake. They also
contain a sequence = number to aid in reconstruction (important
in this case because T= LS 1.3 uses the sequence number to
form the AEAD nonce).

However, as you suggest, an attacker can't DoS DTLS co= nnections by
injecting a small number of packets because the DTLS= stack will just
reject bogus packets.=C2=A0

=
=C2=A0
-Ekr

--001a114edd4a02c1d10525edaf56-- From nobody Wed Dec 2 09:53:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EB71ACD88 for ; Wed, 2 Dec 2015 09:53:42 -0800 (PST) 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] 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 sbubkskpJoFd for ; Wed, 2 Dec 2015 09:53:41 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A6C1ACD86 for ; Wed, 2 Dec 2015 09:53:41 -0800 (PST) Received: by ioir85 with SMTP id r85so53976699ioi.1 for ; Wed, 02 Dec 2015 09:53:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=23+pZ+rCz1PPUFFbBVbocCMb9LOlRgnJNq1Ld2UUxdA=; b=G4rmVXnFejcz2YMm5dlASE04ryy2XgSolE181ELNR3PjHDhLJC2LQJe3gSLoWN7tQ+ 5XkRkAQPwC5rAUBKYgYGO/YcDN7qQwV96MRcZOdHe1ZcGtxRVGDja4MP78wptFuzCuLu wR/eXjC5ThfOoFe4wSK0vdr4yZlQsjxCp0R4O1oFuFG5qLq8d8MsIaJEJLk+UDR4aYFo i30f/2y1RJOHYbzbAAVsnBzej8ZNNNfRUyYPe3+g4Ts/mw77NPRyPxmo2ZookQyL/Ce5 IhTeuzQ8KxqmMFzZVmxAAWLv16h6nI0p3sEqVgYRUkZHb08PQZB2pz3JHQwZeoJBfxNf dPGQ== 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=23+pZ+rCz1PPUFFbBVbocCMb9LOlRgnJNq1Ld2UUxdA=; b=Yx7YF9hqezFaUxUxKcNRalo4sPyfKnVQrQnRrki1YNm1G20hvGM/+8PcoCBUU0RSbn C8FCXftC9Fz6nEPi4dVvBLH5A0GPi15D69DqUSxtIuEcUG4OauJWH0JfeQQFlpU29ETL eAI4I8LEySV1+n+/5yIkqCOosPX1zuyCuwHT6E1yk/I9/TfpIkkwpRc4DduFfVFrpc3R xaFVGVdj5QoZtvDPKX1Y6ZbFFWJThZeZXMaxVIfDRQfZBUMsbkJDAjs5TCuFOpmatU3E vp4JfH+MvzEM3OFCSoFn3d1XQf76E31eNW3r7NxPMeZbkAmZ3MP9Nud1RpuFCm6JHz+T SDGA== X-Gm-Message-State: ALoCoQmkQQsq7ckmfKI2btj3D42O1hb0feQdjtj1LkbMyPR+lhHXiy/8I8Yxjh3V2RFBN8mdx9R3 MIME-Version: 1.0 X-Received: by 10.107.137.19 with SMTP id l19mr4268720iod.138.1449078820954; Wed, 02 Dec 2015 09:53:40 -0800 (PST) Received: by 10.79.70.71 with HTTP; Wed, 2 Dec 2015 09:53:40 -0800 (PST) X-Originating-IP: [89.46.101.168] In-Reply-To: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> References: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> Date: Wed, 2 Dec 2015 17:53:40 +0000 Message-ID: From: Jacob Appelbaum To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 17:53:42 -0000 On 12/2/15, Martin Rex wrote: > Jacob Appelbaum wrote: >> >> I hope that we'll hide the SNI data by default and I understand that a >> discussion about encrypted SNI is currently scheduled for some point >> in the future. > > Hiding SNI data is completely silly security-wise, and any TLSv1.2 > backwards-compatible ClientHello must include a plaintext visible SNI. > Not hiding SNI data is completely silly security wise. SNI data is used by attackers to perform denial of service attacks and to automate man-in-the-middle attacks. We have bare keys in TLS that may also be ephemeral - why would we want to reveal a selector to the network that we know is used for active attacks against the protocol? The question for a few people, myself included, is how we might protect the SNI data in an efficient manner. > So your client will have to know a-priori, out-of-band or be configured > to TLSv1.3-only in order to avoid using a TLSv1.2-compatible ClientHello > with cleartext SNI. > I think that is false. One could easily use the "cleartext" SNI field and insert an encrypted value. A hash of the name would be a simple example but not a secure example, of course. To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less secure and in ways that will only become worse over time. We should remember that TLS 1.3, while not yet finished or deployed, is a future legacy protocol. We shouldn't burden the future with the failures of TLS 1.2 or any other SSL/TLS mistakes of the past. All the best, Jacob From nobody Wed Dec 2 10:00:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFDA1ACCF5 for ; Wed, 2 Dec 2015 10:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 W1BbVIPE-wRR for ; Wed, 2 Dec 2015 10:00:28 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBA51A8977 for ; Wed, 2 Dec 2015 10:00:28 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2A24D16C091; Wed, 2 Dec 2015 18:00:28 +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 140BC16BFA3; Wed, 2 Dec 2015 18:00:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1449079228; bh=POOZAD+SDHqxSISp67G11m+csjGIsZWy/0gf6HYPtiU=; l=1001; h=From:To:CC:Date:References:In-Reply-To:From; b=v7+G2giYiBsHhVwj1JEEK5aP+xgKgp/gmw/dUqt2x5xVNtn1EVyBFWiHY6d5uKUIa 4pp4Y1zPgkJcUJI0UiaopW0Ug/JET3sbxZdndz9XrvdPS/FHg37vIKO/nBwF6hMyfm Qgw98T7BW99JumZ8Qc1LLYjO0ciSQaNUSPJeKBnE= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id EF3381E080; Wed, 2 Dec 2015 18:00:27 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 2 Dec 2015 13:00:27 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Wed, 2 Dec 2015 13:00:27 -0500 From: "Salz, Rich" To: Jacob Appelbaum , "mrex@sap.com" Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all? Thread-Index: AQHRKc4vwBJv/xDF6kerxoHYn7vyUZ6zDYQAgAEO5oCAAH2vgIAAG3yAgADwwYCAAAtCAIAAf4CAgAG7GgCAAAXqAIAAEJQAgAAK8QCAABr7AIAABrGAgAAIT4CAAB1aAP//rLHA Date: Wed, 2 Dec 2015 18:00:26 +0000 Message-ID: <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> 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: [172.19.38.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 18:00:31 -0000 > I think that is false. One could easily use the "cleartext" SNI field and= insert an encrypted value. A hash of the name would be a simple example bu= t not a secure example, of course. Encrypted SNI doesn't give you the kind of protection you think that it doe= s. We (me and a colleague) did a pretty thorough analysis that showed this= . It was not a conclusion we expected, or wanted, to reach. It was prese= nted at the TLS Interim before the IETF in Toronto. Slides should be onlin= e. (For example, the adversary will know the IP address or might not care = about false positives, etc.) In spite of this, another colleague (Brian Sniffen) came up with a way to d= o it at the tail end of the Seattle interim. Encrypt the "true" SNI in the= semi-static DH key of a "fronting" site. And then the front decrypts the = true SNI and forwards to the obscured site. Ekr and dkg presented it in Yok= ohama, but not very well. :) They're presumably working on something bette= r. From nobody Wed Dec 2 10:02:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC5E1ACDA4 for ; Wed, 2 Dec 2015 10:02:24 -0800 (PST) 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, HTML_MESSAGE=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 4DzK5y1pyhn1 for ; Wed, 2 Dec 2015 10:02:22 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA141ACD9B for ; Wed, 2 Dec 2015 10:02:22 -0800 (PST) Received: by ykba77 with SMTP id a77so56038411ykb.2 for ; Wed, 02 Dec 2015 10:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ROSA5OL+CFkVHQ5sJT+sxfrvqcuhvQcDsiNoDzfcaLA=; b=zPmz+TyJDcrPd3BgCgIt7jB91+WKlXIftgF22GsETfMN21QxKHBBrLyxWYM+wJRdux TkNpTDjxyykRSigZyX6tVvQvebS8tOBNebf0lbhsS5JDOvVegsPy+qAs8AFAKeY8rqPZ Lf1hkreiWPtmGLR9QoZkBgepNWjQD3SSVEYGFXMSVVsmgCYeWLVbBDKgGThBs6jkvA0i gEqa5E4U3i5XbIv3MTrnmjt0U/BjT/cSJHyWeO/fN4ir+4lNYk9Oc/MNFPA4RWzfKlqY iu7zRV4s/h9jHOvvE83Jks/zGMKrkQGn+1vPHO4vkKUF+6FhPyjKfxNFqOfVgHlPUJBg D/dA== 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=ROSA5OL+CFkVHQ5sJT+sxfrvqcuhvQcDsiNoDzfcaLA=; b=eFyYIbWiu4IpTfeVcLH5zAZbBEP1jce9NjPy/OVNOzTaFr61sqOO+Ye1JD/V3TRKZM dtn7dz4bZsnlrMPnAQPVtWDHRHAAfaFLAWebd0GCoW5QQ0v6u49bzKVkTSk8ZsnZjgfX 7do4RCnLULb500DnnV83czcIKqqcL92D6lAZnMy/KNuSO48X3ov3fM5p/YsXKz1do8Oj 33QjVgxXSzmV7832X5SAJGZt4UDFvFCGZ6rkCKbxxIArkp0ABt6Bg8RA1WZKL0Kx3Hpe KWRpfHTwb199Y6w4AhtLs/YPYtjottcnKUOLurWeGSfVRI6TaFgfByc6frvQIr+BhOtC gUNA== X-Gm-Message-State: ALoCoQmre/e0gY0zTxB6Erjgnnb3mbH8c3auYZcDonvkyM0++eCvSGR/FCWEnrIDdBGe/0uj4COE X-Received: by 10.129.73.198 with SMTP id w189mr3569125ywa.223.1449079342021; Wed, 02 Dec 2015 10:02:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Wed, 2 Dec 2015 10:01:42 -0800 (PST) In-Reply-To: <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eric Rescorla Date: Wed, 2 Dec 2015 10:01:42 -0800 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a114dc8146ef0d20525ee13b0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 18:02:24 -0000 --001a114dc8146ef0d20525ee13b0 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 2, 2015 at 10:00 AM, Salz, Rich wrote: > > I think that is false. One could easily use the "cleartext" SNI field > and insert an encrypted value. A hash of the name would be a simple example > but not a secure example, of course. > > Encrypted SNI doesn't give you the kind of protection you think that it > does. We (me and a colleague) did a pretty thorough analysis that showed > this. It was not a conclusion we expected, or wanted, to reach. It was > presented at the TLS Interim before the IETF in Toronto. Slides should be > online. (For example, the adversary will know the IP address or might not > care about false positives, etc.) > > In spite of this, another colleague (Brian Sniffen) came up with a way to > do it at the tail end of the Seattle interim. Encrypt the "true" SNI in > the semi-static DH key of a "fronting" site. And then the front decrypts > the true SNI and forwards to the obscured site. Ekr and dkg presented it in > Yokohama, but not very well. :) They're presumably working on something > better. Yes, expect an email with a summary of our current thinking in the next day or so. -Ekr _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114dc8146ef0d20525ee13b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 2, 2015 at 10:00 AM, Salz, Rich <rsalz@akamai.com> wrote:
> I thin= k that is false. One could easily use the "cleartext" SNI field a= nd insert an encrypted value. A hash of the name would be a simple example = but not a secure example, of course.

Encrypted SNI doesn't give you the kind of protection you think = that it does.=C2=A0 We (me and a colleague) did a pretty thorough analysis = that showed this.=C2=A0 It was not a conclusion we expected, or wanted, to = reach.=C2=A0 =C2=A0It was presented at the TLS Interim before the IETF in T= oronto.=C2=A0 Slides should be online.=C2=A0 (For example, the adversary wi= ll know the IP address or might not care about false positives, etc.)

In spite of this, another colleague (Brian Sniffen) came up with a way to d= o it at the tail end of the Seattle interim.=C2=A0 Encrypt the "true&q= uot; SNI in the semi-static DH key of a "fronting" site.=C2=A0 An= d then the front decrypts the true SNI and forwards to the obscured site. E= kr and dkg presented it in Yokohama, but not very well. :)=C2=A0 They'r= e presumably working on something better.

Y= es, expect an email with a summary of our current thinking in the next
day or so.

-Ekr

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

--001a114dc8146ef0d20525ee13b0-- From nobody Wed Dec 2 10:11:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093561ACDD3 for ; Wed, 2 Dec 2015 10:11:54 -0800 (PST) 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] 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 0phPDUhSLPMD for ; Wed, 2 Dec 2015 10:11:53 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229AA1ACDDC for ; Wed, 2 Dec 2015 10:11:52 -0800 (PST) Received: by igvg19 with SMTP id g19so123797421igv.1 for ; Wed, 02 Dec 2015 10:11:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0oHwmb3vLm72Bz2qN3KoSe5E8LSUUhVQKVl5Yov5nMg=; b=xbhDxAw8AtoAiNMvOQec7U98xY+bhh9EaEQgDr2+xw9LrnjOO5kPLrhRdW8jYWmivc 7qes58X3cLJ80aiQRe1lwKBS3KHLnxqT2uwHmQ5ZYu2LxLw9gVIoMaX6hWrBbxRUBbhQ L8LSbhmNTjdtBuJTPj9OFdXNK7r4dqTN2oe+6MhX/bqIW+0hwzT/8GYwAeDgBgbgclfr cn3/9lqUWb72RZeLG8F/1UupqpXyqGrosq1hARk7yKo5pT4vLripifVMS+6kTb5wRMcN xYOv7OsObq2E9bT7x6rl8g03Ay4UvuRBYF5IJ/rWIjwEGjP05NjQ9G0BUhQvounRn+oP 4EMA== 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=0oHwmb3vLm72Bz2qN3KoSe5E8LSUUhVQKVl5Yov5nMg=; b=ZkA0PyDzZCemkcfOY6ASHEhFAD/hXasJM/mH8NmTeHqDcoVZxC7W2QexaC9QrmA1GW lziiTT516P139z92qoXVaJuCD2268aEpTP3EA43GtBHUm4ASgGAzwQtpncHh+KyNsizG 2U5F8dqfD0tQe2uuiUR1o9XQ7CvhUsybd+C4+f55yrX/Tg9vHMb9iKQ8qt/KeAr5zhuJ ngGHyLLry8jPlJT68RDLDcAELT4GRKlQmeSfyWgtFnjtbJhZNJA+bf+iymPymkOHJAbk sF4pjtVqGX8VjA1HT4bug0VJUzE0g2q3vn8Wbg5m31oi3Bmx9j1OHK9XpiZ9Y9Q+3GB8 2Trw== X-Gm-Message-State: ALoCoQlgJgsJeC5ZAb3O0MFAV1FmbMVJAQ2is7N95KXGMT0r/yKvaOGbd/J7sGqo3BcWn9hjomAa MIME-Version: 1.0 X-Received: by 10.50.59.242 with SMTP id c18mr8550604igr.82.1449079911433; Wed, 02 Dec 2015 10:11:51 -0800 (PST) Received: by 10.79.70.71 with HTTP; Wed, 2 Dec 2015 10:11:51 -0800 (PST) X-Originating-IP: [37.187.7.74] In-Reply-To: <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Wed, 2 Dec 2015 18:11:51 +0000 Message-ID: From: Jacob Appelbaum To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 18:11:54 -0000 On 12/2/15, Salz, Rich wrote: >> I think that is false. One could easily use the "cleartext" SNI field and >> insert an encrypted value. A hash of the name would be a simple example >> but not a secure example, of course. > > Encrypted SNI doesn't give you the kind of protection you think that it > does. We (me and a colleague) did a pretty thorough analysis that showed > this. It was not a conclusion we expected, or wanted, to reach. It was > presented at the TLS Interim before the IETF in Toronto. Slides should be > online. (For example, the adversary will know the IP address or might not > care about false positives, etc.) > Without a concrete proposal, I don't think we have any protection. My thoughts were more about the idea that we would *want* protection of SNI data - it seems blindingly obvious to me that we want it as we know SNI is used for attacks in addition to multi-homing tricks. I'm aware that layer issues make for many layers of selectors for attack. If we can avoid adding them in TLS, we can also work on improving things on every level. IP address blocking has the "collateral freedom" problem, of course. > In spite of this, another colleague (Brian Sniffen) came up with a way to do > it at the tail end of the Seattle interim. Encrypt the "true" SNI in the > semi-static DH key of a "fronting" site. And then the front decrypts the > true SNI and forwards to the obscured site. Ekr and dkg presented it in > Yokohama, but not very well. :) They're presumably working on something > better. > I'm certainly interested in reviewing any cryptographic details for a possible SNI protection scheme. It sounds interesting and am looking forward to learning more. All the best, Jacob From nobody Wed Dec 2 10:16:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDA41A1B1D for ; Wed, 2 Dec 2015 10:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 tFi6GEjsMWkf for ; Wed, 2 Dec 2015 10:16:42 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 301D61A01CB for ; Wed, 2 Dec 2015 10:16:42 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8F6314E675; Wed, 2 Dec 2015 18:16:41 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 77B2D4E581; Wed, 2 Dec 2015 18:16:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1449080201; bh=TJvuW/Zz3tAmBps17OKSCeqfbueLVklL8TbviRZWDtA=; l=612; h=From:To:CC:Date:References:In-Reply-To:From; b=FJGfcXbZFGdE4Bup4f19NcwOgSS8k9YZ0pBb2R+zHy/R6hW/Yd5FVJ1OW58KnDzNU FUsTPMW4vearMZo+TdAhOUCMqYYEXf7sXVxdjQgk91Bpm1EgJDTFctAX7uS2L70ouh FxbMeTt/1YbT3vBRWA7vGujuSi+8wkJuollNoYdE= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 740762046; Wed, 2 Dec 2015 18:16:41 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 2 Dec 2015 13:16:41 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Wed, 2 Dec 2015 13:16:41 -0500 From: "Salz, Rich" To: Jacob Appelbaum Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all? Thread-Index: AQHRLSzsNDoobqcUEUSjl7w/yxtl/Z63/9hg Date: Wed, 2 Dec 2015 18:16:40 +0000 Message-ID: <1b5cf52ca90e45bd82f5247ca675dead@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.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: [172.19.38.164] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 18:16:43 -0000 PiBpdCBzZWVtcyBibGluZGluZ2x5IG9idmlvdXMgdG8gbWUgdGhhdCB3ZSB3YW50IGl0DQoNCkZl dyB0aGluZ3MsIHBhcnRpY3VsYXJseSBpbiB0aGUgc2VjdXJpdHkgYXJlbmEsIGFyZSBibGluZGlu Z2x5IG9idmlvdXMuICBJZiBpdCBhY3R1YWxseSBwcm92aWRlcyBubyB0cnVlIHByb3RlY3Rpb24s IHRoZW4gaXQncyBqdXN0IGFzIGJhZCBhcyB0aGUgc2VjdXJpdHkgdGhlYXRlciBpbiBVUyBhaXJw b3J0cy4NCg0KPiBJZiB3ZSBjYW4gYXZvaWQgYWRkaW5nIHRoZW0gaW4gVExTDQoNCldlJ3JlIG5v dCBhZGRpbmcgYW55dGhpbmcgYXMgU05JIGlzIGFscmVhZHkgaW4gcGxhaW50ZXh0LiAgKFByZWNp c2lvbiBjb3VudHM6KS4gIEFuZCB3ZSBoYXZlIGFscmVhZHkgYWRkZWQgbnVtZXJvdXMgaW1wb3J0 YW50IHByaXZhY3kgcHJvdGVjdGlvbnMgdG8gVExTIDEuMy4NCg0KCS9yJA0KDQo= From nobody Wed Dec 2 10:48:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B6F1ACE63 for ; Wed, 2 Dec 2015 10:48:44 -0800 (PST) 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 3H0O1VNGgGQG for ; Wed, 2 Dec 2015 10:48:42 -0800 (PST) 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 741631ACE5E for ; Wed, 2 Dec 2015 10:48:42 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id E99884426C; Wed, 2 Dec 2015 19:48:39 +0100 (CET) X-purgate-ID: 152705::1449082119-00006F99-FD92FAF9/0/0 X-purgate-size: 1043 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id BB16F40454; Wed, 2 Dec 2015 19:48:39 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 8E2D11A39B; Wed, 2 Dec 2015 19:48:39 +0100 (CET) In-Reply-To: To: Jacob Appelbaum Date: Wed, 2 Dec 2015 19:48:39 +0100 (CET) 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: <20151202184839.8E2D11A39B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? 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: Wed, 02 Dec 2015 18:48:44 -0000 Jacob Appelbaum wrote: > On 12/2/15, Martin Rex wrote: >> >> So your client will have to know a-priori, out-of-band or be configured >> to TLSv1.3-only in order to avoid using a TLSv1.2-compatible ClientHello >> with cleartext SNI. > > I think that is false. One could easily use the "cleartext" SNI field > and insert an encrypted value. A hash of the name would be a simple > example but not a secure example, of course. No you can NOT do this (in TLSv1.2 and earlier), because it is entirely backwards-incompatible. Server-side SNI can even be implemented completely outside of the TLS protocol stack (that is how I implemented it). > > To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less > secure That is a myth. > > and in ways that will only become worse over time. We should > remember that TLS 1.3, while not yet finished or deployed, is a future > legacy protocol. TLSv1.3 is looking more and more like a future market failure to me, worse than IPv6. -Martin From nobody Wed Dec 2 11:00:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BF61ACE9D for ; Wed, 2 Dec 2015 11:00:48 -0800 (PST) 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 3ENwAcBvrHpE for ; Wed, 2 Dec 2015 11:00:46 -0800 (PST) Received: from filtteri1.pp.htv.fi (filtteri1.pp.htv.fi [213.243.153.184]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC971ACEA1 for ; Wed, 2 Dec 2015 11:00:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri1.pp.htv.fi (Postfix) with ESMTP id 2218221B764 for ; Wed, 2 Dec 2015 21:00:45 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri1.pp.htv.fi [213.243.153.184]) (amavisd-new, port 10024) with ESMTP id PdKm+caIq+8y for ; Wed, 2 Dec 2015 21:00:45 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id 0141D5BC003 for ; Wed, 2 Dec 2015 21:00:44 +0200 (EET) Date: Wed, 2 Dec 2015 21:00:42 +0200 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20151202190042.GA25439@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 19:00:48 -0000 On Wed, Dec 02, 2015 at 05:53:40PM +0000, Jacob Appelbaum wrote: > > I think that is false. One could easily use the "cleartext" SNI field > and insert an encrypted value. A hash of the name would be a simple > example but not a secure example, of course. Furthermore, SNIs have name type, so even the server_name extension itself could be extended. The length field is 16-bit too... -Ilari From nobody Wed Dec 2 11:23:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104671ACF54 for ; Wed, 2 Dec 2015 11:23:15 -0800 (PST) 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, J_CHICKENPOX_12=0.6, 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 UULcIJXhOS5L for ; Wed, 2 Dec 2015 11:23:12 -0800 (PST) Received: from filtteri5.pp.htv.fi (filtteri5.pp.htv.fi [213.243.153.188]) by ietfa.amsl.com (Postfix) with ESMTP id 238801ACF19 for ; Wed, 2 Dec 2015 11:23:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri5.pp.htv.fi (Postfix) with ESMTP id 31F375A6DE4; Wed, 2 Dec 2015 21:22:53 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri5.pp.htv.fi [213.243.153.188]) (amavisd-new, port 10024) with ESMTP id 3uc9EOMRCKGA; Wed, 2 Dec 2015 21:22:52 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id B95C25BC003; Wed, 2 Dec 2015 21:23:10 +0200 (EET) Date: Wed, 2 Dec 2015 21:23:08 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20151202192308.GA25802@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151201185733.GB15222@LK-Perkele-V2.elisa-laajakaista.fi> <20151202170845.GA25111@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft status and updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 19:23:15 -0000 On Wed, Dec 02, 2015 at 09:29:23AM -0800, Eric Rescorla wrote: > On Wed, Dec 2, 2015 at 9:08 AM, Ilari Liusvaara > wrote: > > > On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote: > > > > > > 3. The server provides g^y in his ServerHello and then g^xy and g^xs > > > are jointly used to produce the traffic keys and also to form a MAC over > > > the handshake. As Hugo pointed out originally, this alone should > > > be sufficient to authenticate the server's side of the connection and > > > you could omit the server CertificateVerify (Hugo, please correct > > > me if I have misunderstood). > > > > Is it guaranteed that the groups are the same? > > Yes, it's a requirement that the groups be the same. If the text doesn't > say that, it should. If the document says that, it is so unclear that I didn't even find the requirement. > > Even if it is, due to implementation bugs, bad idea to rely upon that. > > Can you expand on this point? Is there a specific easy-to-make > implementation error you are concerned with? There is long history of TLS implementations omitting all kinds of checks, even ones explicitly called as MUST. E.g. It would surprise me more not to see any TLS 1.3 implementations that decrypt 0-RTT data with ciphersuite different from negotiated (despite the spec clearly forbidding this) than seeing those. > > > Trying to read between the lines, is your concern that the server is > > > now no longer explicitly signing over the ServerConfiguration in > > > its CertificateVerify [Note that the client continues to do so]? The idea > > > behind removing that was to make the 1-RTT part of the handshake > > > more uniform regardless of whether 0-RTT data was used. > > > I'm certainly open to putting that back in if it's needed, but can you > > > explain your concern in more detail? > > > > The concern is that attacker that has managed to inject g^s for > > known s is able to impersonate the server even through server certificate > > validation on subsequent connections (under some conditions). > > > > I'm sorry, I'm still not following. All the data that the server sends is > tied to > g^y which is signed with the server's certificate, so even if s were > published, > the attacker should not be able to inject data which the client would > accept. I would certainly expect the signature check, if it is there at all, to be proper nonce over SS. IIRC, the key exchange is explicitly intended to be secure (but forward security is lost) if ES is revealed. Config-authenticated ciphersuites are different matter (the main challenge there seems to be deciding when those are to be enabled[1], not so much designing the key exchange[2]). > With that said, it's certainly true that if the attacker is able to > convince the > client that the server has a certain g^a where a is known to the attacker, > then the client has a problem because he will encrypt data *to* the > attacker in 0-RTT, so obviously we are assuming that the attacker does > not know s and cannot convince the client to accept a g^s of his > choice. Oh yeah, that too... I don't work with 0-RTT that much, as it is way harder to analyze than 1-RTT (bad thing, I know). [1] Persistent inpersonation and all that... [2] Require server to send EarlyData if one is used, then just omit server Certificate and CertificateVerify. -Ilari From nobody Wed Dec 2 11:44:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D441B2A0F for ; Wed, 2 Dec 2015 11:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_QP_LONG_LINE=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 wZk2Jv1RyKfO for ; Wed, 2 Dec 2015 11:44:10 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447081B29CE for ; Wed, 2 Dec 2015 11:44:10 -0800 (PST) Received: by pfdd184 with SMTP id d184so1498256pfd.3 for ; Wed, 02 Dec 2015 11:44:09 -0800 (PST) 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=Ypei/GpiVTD4EjVb64IONbyKpoZhGw7dhu7THsKmrus=; b=DS/ty1HTeG9xeq5JCyjCoETAO1mUw+dZkJ7CfLHpGGKpEH6cOvAZrYNhna6DvPHbwx ApHE21ypv5098YpfJ2NIJfRznScPwRn3UNc3ws972AMzKSOuB11b4PdQ0GUfsz0S3zeW /78cS/rtB/ItQd7yhaRYiS56eN7mQhaY5XR/Ozzo5BggvYW5UerZA2/OvgN1rjpGf0xr miiiZngPauj3da8XjeDDM0DMc1TFRW0mfcibHr6vSF3vUPulaSqdfqHQw4AbWZ488pVV 79MODPczzpWX8xivDwmtOjyxK04wNA7D1jNG8R0xCt2Ook8IzqLxAhtTHyQc0jKRlKwl qnQA== X-Received: by 10.98.69.197 with SMTP id n66mr7221848pfi.42.1449085449869; Wed, 02 Dec 2015 11:44:09 -0800 (PST) Received: from [17.247.67.75] ([17.247.67.75]) by smtp.gmail.com with ESMTPSA id l20sm5973816pfi.10.2015.12.02.11.44.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Dec 2015 11:44:08 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-E18D7D4B-25A1-48D0-B561-A62C4238E45D Mime-Version: 1.0 (1.0) From: Fabrice Gautier X-Mailer: iPhone Mail (13A340) In-Reply-To: <1D68EFC9-D5A5-4501-AD7D-0B744AB7428C@gmail.com> Date: Wed, 2 Dec 2015 11:48:47 -0800 Content-Transfer-Encoding: 7bit Message-Id: <92D08A65-285C-4385-A122-817F85B43F37@gmail.com> References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <1D68EFC9-D5A5-4501-AD7D-0B744AB7428C@gmail.com> To: Bryan Ford Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 19:44:13 -0000 --Apple-Mail-E18D7D4B-25A1-48D0-B561-A62C4238E45D Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable > On Dec 2, 2015, at 01:51, Bryan Ford wrote: >=20 >> On 02 Dec 2015, at 00:54, Fabrice Gautier wro= te: >>> On Tue, Dec 1, 2015 at 7:27 AM, Bryan A Ford wro= te: >>>> On 12/1/15 4:02 AM, Fabrice Gautier wrote: >>>> 1) What would be the implications of this for DTLS? (Knowing that one d= ifference between TLS and DTLS is the record header) >>>=20 >>> Good question. Fortunately my proposal should be fairly easy to adapt >>> to DTLS, with one small trick. [=A1=AD] >>=20 >> Hum.... I wouldn't qualify this as a "fairly simple" solution. >=20 > A reasonable but subjective position, which I think we should further disc= uss later if/when this (or some) WG actually revisits DTLS. :) Well, it's objectively several order of magnitude more complex than the curr= ent record framing.=20 And I certainly hope than TLS 1.3 is designed with DTLS in mind.=20 >=20 >>>> 2) In some implementations the record framing/parsing and encryption/de= cryption are down at different layers. Would this proposal make this type of= implementation impossible? >>>=20 >>> Not that I'm aware of, but I might need more information about the >>> specific layering approaches you're thinking of and how "strongly >>> enforced" that layering might be. >>=20 >> For example: >> A TLS library might be logically separated into two main parts: >> 1) A record parsing block, that just take a stream of bytes as in >> input (eg: from a socket) and output a series a record. >> 2) A decrypt function, that take as input full encrypted record and >> output a decrypted one. >>=20 >> There may be various reason to do this: flexibility, clean layering, >> maintainability, testability, etc... >>=20 >> Another reason, maybe performance. For example, a network stack might >> not want to send partial records to the application to decrypt. Having >> a simple way for a network stack to implement TLS framing maybe >> beneficial. Currently it would be fairly simple to implement TLS >> record parsing in a TCP stack. But with your proposal it seems it >> would mean the parsing layer would need to get keys and do crypto. >=20 > In my first proposal, with headers encrypted with a stream cipher (or AEAD= used as one), I think this kind of layering should still be quite feasible,= with the one caveat that the TLS record parsing layer does indeed need to m= ake one new =A1=B0call=A1=B1 into the crypto-related code (to get the header= ) in addition to the one it already does (to pass the body and header to the= crypto code for body-decryption and integrity-check). =20 That is one big caveat. And you description doesn't really match what I have= in mind.=20 In particular, currently, record framing and decryption doesn't need to be s= ynchronous and there is no particular requirement for which one call the oth= er. So a TLS record framing implemented in an OS kernel TCP stack would not "cal= l" into the decryption layer in userland. It would just queue data in its so= cket buffer and only signal to userland that data is available when a full r= ecord is available to be decrypted. So it just wouldn't be practical to do this at all with your scheme. > And only on the receive path; the send path seems pretty much unaffected. = This doesn=A1=AFt seem like a big layering problem to me, but again subject= ive opinions may vary. >=20 > In my second proposal, with headers fully encrypted and integrity-checked a= long with the body, I think the opportunity for the clean layering you propo= se comes back and perhaps gets even better: it=A1=AFs just that the record w= riting/parsing now happens *inside* rather than outside the encryption bound= ary. In other words, their order is reversed: the sender invokes the record= -writing code first, then the AEAD encryption code to encrypt everything (he= ader and data) at once; the receiver flow invokes the AEAD decryption code f= irst to decrypt everything, For my example above, the second proposal requires that the application laye= r tell the network stack what the expected size of the next record is.=20 For some implementation it may be more efficient as the decryption layer (in= the application) knows exactly how much data it needs to read from the sock= et - whereas today you need to read the header first, then the rest.=20 But it still doesn't allow the network stack to - on its own - signal to the= application when it received enough data ready to be decrypted. > then invokes the separately-modularized record parsing code on the already= fully decrypted and integrity-checked record content. This seems even clea= ner to me than the current approach, where the record parsing code has to do= some (very careful!) parsing of the record before it=A1=AFs been authentica= ted, The current header is so simple there is virtually no risk to get the framin= g wrong, and nothing really bad happen even if you do get it wrong. =20 > then invoke decryption, then do some more internal parsing on the decrypte= d AEAD body (e.g., the encrypted content-type within). >=20 > B --Apple-Mail-E18D7D4B-25A1-48D0-B561-A62C4238E45D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Dec 2, 2015, at 01:5= 1, Bryan Ford <brynosaurus@gmail= .com> wrote:

On 02 Dec 2015, a= t 00:54, Fabrice Gautier <fabrice.gautier@gmail.com> wrote:
On Tue, Dec 1, 2015 at 7:27 AM, Bryan A Ford <brynosaurus@gmail.com> wrote:
On 12/1/15 4:02 AM, Fabrice Gautier wrote:
1) What would be the implications of this f= or DTLS? (Knowing that one difference between TLS and DTLS is the record hea= der)

Good question.  Fortunat= ely my proposal should be fairly easy to adapt
to DTLS, with o= ne small trick. [=E2=80=A6]

Hum.... I wouldn't qualify this as a "f= airly simple" solution.

A reasonable but subjective position, which I think we should f= urther discuss later if/when this (or some) WG actually revisits DTLS. :)

Well, it's objectively several or= der of magnitude more complex than the current record framing. 
And I certainly hope than TLS 1.3 is designed with DTLS in mind.=  


2) In some implementations the record= framing/parsing and encryption/decryption are down at different layers. Wou= ld this proposal make this type of implementation impossible?
=

Not that I'm aware of, but I might need more inf= ormation about the
specific layering approaches you're thinkin= g of and how "strongly
enforced" that layering might be.

For example:
 A TLS library might be logically separated into two main par= ts:
1) A r= ecord parsing block, that just take a stream of bytes as in
input (eg: from a socket) an= d output a series a record.
2) A decrypt function, that take as input full encrypted r= ecord and
output a decrypted one.

There may be various reason to do this: flexibility, c= lean layering,
maintainability, testability, etc...

Another reason, maybe performance= . For example, a network stack might
not want to send partial records to the applicatio= n to decrypt. Having
a simple way for a network stack to implement TLS framing maybe<= /span>
beneficia= l. Currently it would be fairly simple to implement TLS
record parsing in a TCP stack= . But with your proposal it seems it
would mean the parsing layer would need to get key= s and do crypto.

In my first proposal, with headers encrypted with a stream cipher (or A= EAD used as one), I think this kind of layering should still be quite feasib= le, with the one caveat that the TLS record parsing layer does indeed need t= o make one new =E2=80=9Ccall=E2=80=9D into the crypto-related code (to get t= he header) in addition to the one it already does (to pass the body and head= er to the crypto code for body-decryption and integrity-check).  
=

That is one big caveat. And you= description doesn't really match what I have in mind. 

<= /div>
In particular, currently, record framing and decryption doesn't ne= ed to be synchronous and there is no particular requirement for which one ca= ll the other.

So a TLS record framing implemented i= n an OS kernel TCP stack would not "call" into the decryption layer in userl= and. It would just queue data in its socket buffer and only signal to userla= nd that data is available when a full record is available to be decrypted.

So it just wouldn't be practical to do this at all w= ith your scheme.

And only o= n the receive path; the send path seems pretty much unaffected.  This d= oesn=E2=80=99t seem like a big layering problem to me, but again subjective o= pinions may vary.

In my second proposal,= with headers fully encrypted and integrity-checked along with the body, I t= hink the opportunity for the clean layering you propose comes back and perha= ps gets even better: it=E2=80=99s just that the record writing/parsing now h= appens *inside* rather than outside the encryption boundary.  In other w= ords, their order is reversed: the sender invokes the record-writing code fi= rst, then the AEAD encryption code to encrypt everything (header and data) a= t once; the receiver flow invokes the AEAD decryption code first to decrypt e= verything,

For my example= above, the second proposal requires that the application layer tell the net= work stack what the expected size of the next record is. 
For some implementation it may be more efficient as the decrypti= on layer (in the application) knows exactly how much data it needs to read f= rom the socket - whereas today you need to read the header first, then the r= est. 
But it still doesn't allow the network stack to - on it= s own - signal to the application when it received enough data ready to be d= ecrypted.

then invokes the= separately-modularized record parsing code on the already fully decrypted a= nd integrity-checked record content.  This seems even cleaner to me tha= n the current approach, where the record parsing code has to do some (very c= areful!) parsing of the record before it=E2=80=99s been authenticated,

The current header is so simpl= e there is virtually no risk to get the framing wrong, and nothing really ba= d happen even if you do get it wrong.
 

<= br>
then invoke decryption, then do s= ome more internal parsing on the decrypted AEAD body (e.g., the encrypted co= ntent-type within).

B
<= /blockquote>
= --Apple-Mail-E18D7D4B-25A1-48D0-B561-A62C4238E45D-- From nobody Wed Dec 2 12:13:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF3C1B2C8B for ; Wed, 2 Dec 2015 12:13:54 -0800 (PST) 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 avX0Jg8kSh54 for ; Wed, 2 Dec 2015 12:13:52 -0800 (PST) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75FFC1B2C84 for ; Wed, 2 Dec 2015 12:13:52 -0800 (PST) Received: by qgec40 with SMTP id c40so43099523qge.2 for ; Wed, 02 Dec 2015 12:13:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=+viA8VNQTQfYLGiBZdVa5okqWxHJQq83X/0oOxrpVMc=; b=zttygfWUi6jT7lGy9rloxwbqRiWoMt26ota5NGgAyLiL7d/Gkxy6B09XQ0ubBtg5nR Su2ApqVs6prURE4psvmqXz+eb9pp/cnYQnWW31Am5JovQTd4qLRzlO5ahDN/IJd9p1sr yN3yMBKlXrj4wNveRr6SuOZ3LBxqcaO/EYdBHbBo1f8xKp53JSxTrNRXUAlYITCjg/Rf PXvq5ZNTsfgo4fQSSCRDJtv1B6UnJjMpkbAg9/bYvxSAiabaoEruVcCqXeNbDkeiAdXb MJzHwWEInHq9ukbJuRP3fTez0owUcz6i5ZV6t7PMoKRUzk8mL6MY1pvB2ZsXkTKqdYmh vfAQ== X-Received: by 10.140.155.75 with SMTP id b72mr6583986qhb.29.1449087231662; Wed, 02 Dec 2015 12:13:51 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id q133sm1863820qhq.20.2015.12.02.12.13.50 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 02 Dec 2015 12:13:51 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Wed, 2 Dec 2015 15:13:49 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201512021513.49894.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] =?iso-8859-1?q?Encrypting_record_headers=3A_practical_for_T?= =?iso-8859-1?q?LS_1=2E3_after=09all=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 20:13:54 -0000 On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote: > Encrypted SNI doesn't give you the kind of protection you think that it does. We (me and a colleague) did a pretty thorough analysis that showed this. It was not a conclusion we expected, or wanted, to reach. It was presented at the TLS Interim before the IETF in Toronto. Slides should be online. (For example, the adversary will know the IP address or might not care about false positives, etc.) URL from Rich's previous email citing this: https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view Please don't brush this argument off in favor of the "obvious" answer that encrypted SNI is helpful. The sad truth is that it's a lot of effort with a lot of risk for virtually no gain. I was quite in favor of encrypted SNI before reading it, and I had to concede the point after. If we can come up with a way to do it easily, ok, but it's not an avenue worth spending too much time on. Dave From nobody Wed Dec 2 15:36:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFEC1AD0B9 for ; Wed, 2 Dec 2015 15:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 qO0_ztXlZXhX for ; Wed, 2 Dec 2015 15:36:04 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7781AD0AF for ; Wed, 2 Dec 2015 15:36:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1449099364; x=1480635364; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jBE+p2+HyCwZyuDsik4rTDwgy4fc8z+GXgOW4x6zYmU=; b=hwvG+Z/H9wrSu1JR6O9aQUQVWh/s3Po84LPQSSd+xPmX8O6jaWwT1Edt 3NJrMZeKfsAXZk0ZwjBXCPdCfzbTtgFgrnvuHq4gRp7AJIe3hUADhgxML PBq6vneY9ZUZVDrEAV/rg6ftbZiZmoEwdPaVpY8P9w7+kpFq+Py3FZTMP 5G0ZkPNfztgfGIAOPaRluTN+tkwjHcdIY3XB/exwuJMfIo66sIe59eX72 le3BLjknQZma8/VAOMsygGgVPClsnyi4nsPL+r0O9duQaQ8pT2yA/ri+c JXsGP1aLxQVI33fvylBx5Ac8rKq8bUPecNxRgNHQtMUBL5pV8y6oXwJnQ Q==; X-IronPort-AV: E=Sophos;i="5.20,375,1444647600"; d="scan'208";a="57330855" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe1.UoA.auckland.ac.nz) ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Dec 2015 12:36:01 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Thu, 3 Dec 2015 12:36:01 +1300 From: Peter Gutmann To: Bryan Ford Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all? Thread-Index: AQHRLOi8exSx9f5oS0GRoAMeoC+Kxp64WmlC Date: Wed, 2 Dec 2015 23:36:00 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B97279@uxcn10-5.UoA.auckland.ac.nz> References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4B95D5F@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Dec 2015 23:36:07 -0000 Bryan Ford writes:=0A= =0A= >We have repeatedly stated several relevant threat models here; you just = =0A= >don=92t seem to be accepting them as threat models for some reason. =0A= =0A= That's because they're not actual threat models, just handwringing about=0A= vague, undefined bogeymen. Yoav Nir has made a good start, although it's= =0A= more a wish list than a threat model, or at least a list of desirable =0A= properties for the system to have. In crypto terms, it's like stating=0A= "I want my cryptosystem to be IND-CPA". The threat there is an adversary= =0A= being able to encrypt various plaintext messages and being able to =0A= distinguish them based on the ciphertext. You can pretty clearly say=0A= that against this threat (stage #1 of my list), you need an IND-CPA=0A= ciphersystem (stage #2). From there you can decide whether it's worth=0A= doing this, stage #3 (OK, any cryptosystem worth its salt had better be =0A= IND-CPA, so that's a tautology).=0A= =0A= OTOH an IND-CPA cryptosystem isn't necessarily secure against an=0A= adative chosen ciphertext attack, a different type of threat, so you =0A= need to up the defence to an IND-CCA2 secure system.=0A= =0A= Give me an actual threat model of the type(s) illustrated above, write =0A= down the exact capabilities of the attacker so we know what to=0A= defend against, and then we can disagree on it.=0A= =0A= >We have been doing this as well, repeatedly. =0A= =0A= No, you've just been saying "here's my pet idea, TLS should adopt it"=0A= over and over again. I'm happy to keep saying "it doesn't provide=0A= the protection you seem to think it does, it restricts TLS to only=0A= using AEAD stream ciphers, and it causes serious headaches for=0A= implementations" as often as you keep repeating "here's my pet idea,=0A= we should use it".=0A= =0A= Peter.=0A= From nobody Wed Dec 2 16:52:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C811AD305 for ; Wed, 2 Dec 2015 16:52:42 -0800 (PST) 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] 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 YXfqJRpxsDpl for ; Wed, 2 Dec 2015 16:52:41 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6BD61AD2A9 for ; Wed, 2 Dec 2015 16:52:41 -0800 (PST) Received: by iouu10 with SMTP id u10so66430915iou.0 for ; Wed, 02 Dec 2015 16:52:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NtlOfplNRPLPmZm+/pKLQmC+cgfxLmD9S8wgPJZyqus=; b=PMBdHubvvZYe/+uGdAFhVfx73z+u8B6To8uliDe9oxkv3GtfCuzW4/oB352tQvcSUr 6cBnvHf7o8I2M2Hw59TnagMSoGQIupqguzRTO2zyBGy7GtyNZsMYHzfo2NXhlHEUkn5g +pCALKEuPopE67f/YFzyoSPyFu39efavZjBraYGjMQBai3F8qGjCs2V7TmGt6rhu8Cme sNlUO8HSa0lMwjoh3+tLFZawAXDdHYhfxyk4b0zH6qpvENt9yEPJrxVHIiSKht0jnTuj xNJ8pqLwJCQauTvrR2S9RY9M94nXI/DFdriz/DRDSO6/P9VubqeyIkwc+89OJAvD7iFQ HznA== 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=NtlOfplNRPLPmZm+/pKLQmC+cgfxLmD9S8wgPJZyqus=; b=bepwINCxJopTvgixQ1/4x9SCp5G6UoYCg7l39MT1JY1oHUtbZjrCJBHQsIs15GBFHP miE6UvfBfnFhpZyO1r5eX4QYvFSHWahiDXGzhymPx3nU5zfLUK2/Y7tzQtevzpITFq9k I0+fO4RmlYap+cxSz0/+4dtNiGYYJ7Q7UdMBJLWbTEAnhIv/QZ24DSdznxx5KdzX3k4q KOy7UY/bcXpb6PgH6ST5ndTwVFz57cYcAsxMqltvtGbtSdFikKB21x12NFzbDpxqkfZd xMf7lUKdVC1dtCMq5uJZo9OG9Ry200j28iwaPLa4kP3zAVQl7AGhFv9a2jqoSgaNhO9i tqIg== X-Gm-Message-State: ALoCoQl6K8tjcb3fmio1v1I7H0L5K5uXhuUj5PpRJIdgub2/54eE19oSWVjKl3B0BdRvB41Mauve MIME-Version: 1.0 X-Received: by 10.107.138.28 with SMTP id m28mr7423920iod.24.1449103960011; Wed, 02 Dec 2015 16:52:40 -0800 (PST) Received: by 10.79.70.71 with HTTP; Wed, 2 Dec 2015 16:52:39 -0800 (PST) X-Originating-IP: [171.25.193.132] In-Reply-To: <1b5cf52ca90e45bd82f5247ca675dead@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <1b5cf52ca90e45bd82f5247ca675dead@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Thu, 3 Dec 2015 00:52:39 +0000 Message-ID: From: Jacob Appelbaum To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 00:52:43 -0000 On 12/2/15, Salz, Rich wrote: >> it seems blindingly obvious to me that we want it > > Few things, particularly in the security arena, are blindingly obvious. If > it actually provides no true protection, then it's just as bad as the > security theater in US airports. It provides protection. Specifically it provides confidentially. It doesn't solve the fact that the DNS is a privacy violating nightmare. It doesn't change the fact that the NSA breaks the rules. > >> If we can avoid adding them in TLS > > We're not adding anything as SNI is already in plaintext. (Precision > counts:). And we have already added numerous important privacy protections > to TLS 1.3. Leaving SNI in the clear ensures that attackers will be able to selectively block access by name with ngrep and some basic TCP RST injection. No cryptographic attacks are required and it will be done by simply looking for an objectionable string. The economics of that attack are very low. Forcing an attacker to become a global active or passive adversary and to perform competent traffic analysis is a much higher economic cost. All the best, Jacob From nobody Wed Dec 2 17:01:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E171AD377 for ; Wed, 2 Dec 2015 17:01:19 -0800 (PST) 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] 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 H7nT39d8r-3D for ; Wed, 2 Dec 2015 17:01:18 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A3C61AD374 for ; Wed, 2 Dec 2015 17:01:18 -0800 (PST) Received: by igcmv3 with SMTP id mv3so2572730igc.0 for ; Wed, 02 Dec 2015 17:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wP0rGO7CyEuJ3MB9j2lIvMSGqc+R6Q3ea1WPHpXBGQc=; b=0mAtGlGGvkhIcU0awzvmYf0iNLriiY8OlQcOt/VAE6eyFIYpURT66tTQ2+UBSJmhNd BSWBG0UxPgArvs2fRjuxHw/D0ZeFj4UNzDNhD2oXrgK4R2/jEdOw1HjqKuJF1p8uSWNW x2vZkXxXOAcwCNmqmwBPGFQ29jPyGrxR3INJlu9gjke4VgMNIOm6bwgZhcNpjNbUuBNW dFeEAN/7kH/dheejBCxbc2bcx8vYf+cdmbGaHsp00EIYSTMCHMW3LI+HVLfZqQuigAUo qGEuSKY9weTTSD55U7NhXstfEJ4xh5aVmQ7W3chMX+OrK4afF9plulVdU5xXB96f+3+e TPfw== 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=wP0rGO7CyEuJ3MB9j2lIvMSGqc+R6Q3ea1WPHpXBGQc=; b=kFYPtAsawOM3NwE2etym+VJ9LEYgEjOJ0fxgXgYtxNjeWahZ/8lAI4z6D+JMY7yUyS V/VVZYBzH5+hSJgDcHaymgy/87xhaP4rx/riyqhBUdpXxFJ3Xz9GuLymZzb34QK9dyeg vx7sT1VIWCSC22ca0dnuBM13GnyQg/Dh+rSXuDxoX7WiWSlt/2Fp3YMjAtCaUgLbX5bi T3XWrUlEl6E9yBhuCyWmQ36JtYGBE/pKxyDP5KNkHSnmFe8SceHPGv5mqFYdCBjlSwLC H0vCBn+b4cgdzYcTwEYkJcpL4JV0zj04Fc41GhoOY4BuRZoTuuneVUi6dvSKb7CWdrsT 6ZnA== X-Gm-Message-State: ALoCoQlnPIz4lXNnX5X+r6+Uugd5mT6E64Wt7OJCdq002OBBaPARQLtIYA87Yop3JK8rSXv4IUm8 MIME-Version: 1.0 X-Received: by 10.50.225.1 with SMTP id rg1mr16175756igc.78.1449104477553; Wed, 02 Dec 2015 17:01:17 -0800 (PST) Received: by 10.79.70.71 with HTTP; Wed, 2 Dec 2015 17:01:17 -0800 (PST) X-Originating-IP: [171.25.193.132] In-Reply-To: <20151202184839.8E2D11A39B@ld9781.wdf.sap.corp> References: <20151202184839.8E2D11A39B@ld9781.wdf.sap.corp> Date: Thu, 3 Dec 2015 01:01:17 +0000 Message-ID: From: Jacob Appelbaum To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 01:01:19 -0000 On 12/2/15, Martin Rex wrote: > Jacob Appelbaum wrote: >> On 12/2/15, Martin Rex wrote: >>> >>> So your client will have to know a-priori, out-of-band or be configured >>> to TLSv1.3-only in order to avoid using a TLSv1.2-compatible ClientHello >>> with cleartext SNI. >> >> I think that is false. One could easily use the "cleartext" SNI field >> and insert an encrypted value. A hash of the name would be a simple >> example but not a secure example, of course. > > No you can NOT do this (in TLSv1.2 and earlier), because it is entirely > backwards-incompatible. If I configure a vhost to respond to a sha1(example.com) and have a way to visit sha1(example.com) in a browser, I think it doesn't even break the spec. That doesn't really matter - the point was to suggest that there are many ways to solve this problem. Assuming a shared key, we can easily take a field and transform it. There are compelling reasons to do it and there are active attackers who are exploiting the lack of confidentiality in TLS. > > Server-side SNI can even be implemented completely outside of the TLS > protocol stack (that is how I implemented it). I'm curious - are you saying that if the value was encrypted... it would become impossible to implement it outside of the TLS protocol stack? Or is this just an aside? > >> >> To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less >> secure > > That is a myth. Are you asserting that TLS 1.3 will be less secure or equally secure here? >> >> and in ways that will only become worse over time. We should >> remember that TLS 1.3, while not yet finished or deployed, is a future >> legacy protocol. > > TLSv1.3 is looking more and more like a future market failure to me, > worse than IPv6. Without privacy on the internet, I'll see your market and raise you a TCP RST. All the best, Jacob From nobody Wed Dec 2 17:46:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91EF1B2B13 for ; Wed, 2 Dec 2015 17:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 UUMlWibgWsQJ for ; Wed, 2 Dec 2015 17:46:36 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 655C01B2B14 for ; Wed, 2 Dec 2015 17:46:36 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E95A0496C08; Thu, 3 Dec 2015 01:46:35 +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 D3901496C05; Thu, 3 Dec 2015 01:46:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1449107195; bh=OwPBx3ZQS2M/islt5M29A32cFeJRVPBz7zZQJFrbYDo=; l=374; h=From:To:CC:Date:References:In-Reply-To:From; b=asAQm4nkBPsNF059k5n10D8Y4++1E75yLFk2LWrEf7ORnzYYidSgojXAdjQOkoOpv A8C0m0AaOtbC+I3wUR0go2534N81Ff/5X8uyIQRH5t1lRH9dqNRkzPBHCdzdBtD54S zlqpawt95T6bEz9SkolouazsfN6BXW40HETaSQQg= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id B76851E08A; Thu, 3 Dec 2015 01:46:35 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 2 Dec 2015 20:46:34 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Wed, 2 Dec 2015 20:46:34 -0500 From: "Salz, Rich" To: Jacob Appelbaum Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all? Thread-Index: AQHRLSzsNDoobqcUEUSjl7w/yxtl/Z63/9hggADDcID//7pfcA== Date: Thu, 3 Dec 2015 01:46:34 +0000 Message-ID: <60e21928e9174d8ea7eb84b00ad85884@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <1b5cf52ca90e45bd82f5247ca675dead@usma1ex-dag1mb1.msg.corp.akamai.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: [172.19.38.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 01:46:37 -0000 PiBJdCBwcm92aWRlcyBwcm90ZWN0aW9uLiBTcGVjaWZpY2FsbHkgaXQgcHJvdmlkZXMgY29uZmlk ZW50aWFsbHkuDQoNCkl0IGlzIGZhciBmcm9tIGNsZWFyIHRoYXQgdGhlIHByaXZhY3kgZ2FpbnMg YW55dGhpbmcgaW4gdGhlIGZvcm0gb2YgcHJhY3RpY2FsIHByb3RlY3Rpb24uICBIYXZpbmcgbG9v a2VkIGF0IGl0LCBJJ20gdW5jb252aW5jZWQuICBBbmQgSSd2ZSBiZWVuIGEgcHJpdmFjeS9jcnlw dG8gYWR2b2NhdGUgZm9yIGEgdmVyeSB2ZXJ5IGxvbmcgdGltZS4NCg0KDQo= From nobody Wed Dec 2 17:55:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6EB1B2B62 for ; Wed, 2 Dec 2015 17:55:39 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 pAyO9j5eAk3l for ; Wed, 2 Dec 2015 17:55:38 -0800 (PST) Received: from sasl.smtp.pobox.com (pb-smtp0.int.icgroup.com [208.72.237.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE81D1B2B2C for ; Wed, 2 Dec 2015 17:55:37 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id 3AC3C30AC9 for ; Wed, 2 Dec 2015 20:55:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=z1kIFSK/CQssOimy+rECefu6F48=; b=lBqFsB HImjuwzh8JSmfANS0Q5CtxkUjIvyN5036ADvuUxio+Ze9PnW5dr7mapzEOn4YJTH 2QLj5xbn43ca4lJ1sMS/yjEKqEAaj/agbhXP97IrVCHk7O5i7DGfZasmcj5qGJer 06AX96CwjlQVKH1E+0Osvz/KaTyhT285nXqho= Received: from pb-smtp0.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id 33BBD30AC8 for ; Wed, 2 Dec 2015 20:55:37 -0500 (EST) Received: from mail-ig0-f174.google.com (unknown [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp0.pobox.com (Postfix) with ESMTPSA id A645830AC4 for ; Wed, 2 Dec 2015 20:55:36 -0500 (EST) Received: by igcto18 with SMTP id to18so1934304igc.0 for ; Wed, 02 Dec 2015 17:55:34 -0800 (PST) X-Received: by 10.50.57.44 with SMTP id f12mr34054359igq.29.1449107734650; Wed, 02 Dec 2015 17:55:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.2.70 with HTTP; Wed, 2 Dec 2015 17:54:54 -0800 (PST) In-Reply-To: References: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <1b5cf52ca90e45bd82f5247ca675dead@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eric Mill Date: Wed, 2 Dec 2015 20:54:54 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Jacob Appelbaum Content-Type: multipart/alternative; boundary=e89a8ff24d9dc3e4b80525f4afeb X-Pobox-Relay-ID: F25FB6DE-9960-11E5-AD22-6BD26AB36C07-82875391!pb-smtp0.pobox.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 01:55:39 -0000 --e89a8ff24d9dc3e4b80525f4afeb Content-Type: text/plain; charset=UTF-8 On Wed, Dec 2, 2015 at 7:52 PM, Jacob Appelbaum wrote: > On 12/2/15, Salz, Rich wrote: > >> it seems blindingly obvious to me that we want it > > > > Few things, particularly in the security arena, are blindingly obvious. > If > > it actually provides no true protection, then it's just as bad as the > > security theater in US airports. > > It provides protection. Specifically it provides confidentially. > > It doesn't solve the fact that the DNS is a privacy violating > nightmare. It doesn't change the fact that the NSA breaks the rules. > And what Don and Rich's analysis is trying to isolate is how much real protection you get from that level of confidentiality, so that a decision that weighs all available factors can be made, including the complexity cost. It's not just a collective action problem because DNS isn't encrypted too. Their analysis also looks at what you get when both are encrypted. And regardless of DNS being encrypted, rainbow-table style reverse lookups of IP to DNS name are always possible. That doesn't mean encrypted SNI isn't worth it -- it clearly provides a security attribute (confidentiality) to an important piece of information. But it's not enough to drive ahead and say that some attribute outweighs every other consideration. For example, HSTS' persistence of memory can be abused as a tracking device: http://zyan.scripts.mit.edu/sniffly/ And this was known at the time the spec was finalized: https://tools.ietf.org/html/rfc6797#section-14.9 But HSTS creates security benefits that are well worth the cost of that tracking potential (which can also be mitigated through preloading). There are a lot of browsers and communities which use and advocate for HSTS that might generally balk at creating tracking devices. I'm not advocating a strong stance on whether encrypted SNI is worth pursuing, or whether TLS record headers should be encrypted in TLS 1.3. But it's useful to keep the debate framed in its full context, rather than narrowing it to a black-and-white discussion over whether a generally good attribute is good or not. -- Eric --e89a8ff24d9dc3e4b80525f4afeb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Dec 2, 2015 at 7:52 PM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
On 12/2/15, Salz, Rich <rsalz@akamai.com> wrote: >> it seems blindingly obvious to me that we = want it
>
> Few things, particularly in the security arena, are blindingly obvious= .=C2=A0 If
> it actually provides no true protection, then it's just as bad as = the
> security theater in US airports.

It provides protection. Specifically it provides confidentially.

It doesn't solve the fact that the DNS is a privacy violating
nightmare. It doesn't change the fact that the NSA breaks the rules.

And what Don and Rich's analysis is t= rying to isolate is how much real protection you get from that level of con= fidentiality, so that a decision that weighs all available factors can be m= ade, including the complexity cost.=C2=A0

It's= not just a collective action problem because DNS isn't encrypted too. = Their analysis also looks at what you get when both are encrypted. And rega= rdless of DNS being encrypted, rainbow-table style reverse lookups of IP to= DNS name are always possible. That doesn't mean encrypted SNI isn'= t worth it -- it clearly provides a security attribute (confidentiality) to= an important piece of information.=C2=A0

But it&#= 39;s not enough to drive ahead and say that some attribute outweighs every = other consideration. For example, HSTS' persistence of memory can be ab= used as a tracking device:

http://zyan.scripts.mit.edu/sniffly/

And this was known at the time the spec was finalized:=

<= div>
But HSTS creates security benefits that are well worth t= he cost of that tracking potential (which can also be mitigated through pre= loading). There are a lot of browsers and communities which use and advocat= e for HSTS that might generally balk at creating tracking devices.

I'm not advocating a strong stance on whether encrypte= d SNI is worth pursuing, or whether TLS record headers should be encrypted = in TLS 1.3. But it's useful to keep the debate framed in its full conte= xt, rather than narrowing it to a black-and-white discussion over whether a= generally good attribute is good or not.

-- Eric<= /div>
--e89a8ff24d9dc3e4b80525f4afeb-- From nobody Wed Dec 2 19:38:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF45F1A0126 for ; Wed, 2 Dec 2015 19:38:42 -0800 (PST) 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] 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 EGpnBNNmHnvW for ; Wed, 2 Dec 2015 19:38:41 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35A781A0024 for ; Wed, 2 Dec 2015 19:38:41 -0800 (PST) Received: by igcto18 with SMTP id to18so3273476igc.0 for ; Wed, 02 Dec 2015 19:38:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u85cvTrVNmAeFdbwLxtlbim8XSsupzSZ4XlZP7+rzKA=; b=DgQZ/4QrFf99mZMy38SZiVGwXkhLr/vcy9RdWoRaS+t4Glj7VTRFjsUbix1dZ/j9TP mu4qdW9UoUnaEYh/2GAVe9EJqwnUtFm/M6ZiIc5YX2hU/33VCqwdy/febJKCzc2ZGcbt XQo1EeiybGt4JgeXGjqekgpGZbhFOOherPUu47sCKQAR/jTGV718Ex3kh2RQa30q9CAS MzXGYyiqso1kaS7GwkTmV0qh5br79z2nLvFt0uJ5aD5P40ZCGFostFf+dPpDonuklj82 hxLUSgSf4hGzX16ewG3S6voA7fYw53jHDCOiJMbauqLOkk2n5+emHmuF6b+OlDz3cQFz KOvg== 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=u85cvTrVNmAeFdbwLxtlbim8XSsupzSZ4XlZP7+rzKA=; b=WXOmubgkLGZi0OAbUcOZK3rufKf60qVsR9/VZ4bsi/xeEWe8eT5nmTXSleQz+SS3+W NBPTwK0K6ntR2vfP8WF05hXgH9AulC+at4D9RD+O34m3opmoIjPW7TqoRkS4vk8IMjcf Kt9Td/5XmTn08Lzh1huHLXb9/+PjZD3bUGxgR/viUfyLISR4NB1EimvlajVo9uykYkXV Gl9hewhPKodVrw7T4nlf+4seTxT0LnBewasGoWuPxVVISoGCNC1Bml1UZSkorx2ZYhPs UkNXePI2XbqzmkD2uDdFLfspBikBnm3uqdUsqjKzRRtDDqDsatCvNatUc3L+unYd9Xdg xcaQ== X-Gm-Message-State: ALoCoQlbCrBTLfynlYw4cVsJReCbt5VDvkD9CQrUT+ojjECSHU/2zzQ/WKUQhah/o0rBlXAXiTVL MIME-Version: 1.0 X-Received: by 10.50.49.109 with SMTP id t13mr36611516ign.89.1449113920501; Wed, 02 Dec 2015 19:38:40 -0800 (PST) Received: by 10.79.70.71 with HTTP; Wed, 2 Dec 2015 19:38:39 -0800 (PST) X-Originating-IP: [46.188.10.23] In-Reply-To: <201512021513.49894.davemgarrett@gmail.com> References: <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <201512021513.49894.davemgarrett@gmail.com> Date: Thu, 3 Dec 2015 03:38:39 +0000 Message-ID: From: Jacob Appelbaum To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 03:38:42 -0000 On 12/2/15, Dave Garrett wrote: > On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote: >> Encrypted SNI doesn't give you the kind of protection you think that it >> does. We (me and a colleague) did a pretty thorough analysis that showed >> this. It was not a conclusion we expected, or wanted, to reach. It was >> presented at the TLS Interim before the IETF in Toronto. Slides should be >> online. (For example, the adversary will know the IP address or might not >> care about false positives, etc.) > > URL from Rich's previous email citing this: > https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view > I've read these slides. I'm... at a bit of a loss. The entire slide deck seems so flippant as to be not worth addressing. It just doesn't even pass the giggle test. Though upon reading it, I am struck by two core points: One is that big companies will be pressured by governments. Ironically, Akamai isn't one of those as they're willingly in bed with governments around the world. But I guess as the slides say, the author isn't speaking on behalf of Akamai. That said - good, I want governments to have to go to a company rather than to the user - the company may have a legal team, the user may have hidden or otherwise protected themselves. Hopefully the company is in a position to do nothing or will take action to protect the user's basic liberties. The second is a constant security nihilism. Yeah, a lot of stuff is broken - so lets acknowledge it bit by bit and then fix it all. I would encourage everyone to read the slides as the conclusion in the presentation simply do not follow. If I had been in the audience when they were presented, I would have been at the microphone objecting. The idea that this convinced anyone is baffling. It is clear that privacy concerns exist in many many different protocols and that many protocols need to be fixed. Many people point at other protocols as a way to punt on the issue for their own protocol. The cycle continues and the privacy violations continue without end. > Please don't brush this argument off in favor of the "obvious" answer that > encrypted SNI is helpful. The sad truth is that it's a lot of effort with a > lot of risk for virtually no gain. I was quite in favor of encrypted SNI > before reading it, and I had to concede the point after. If we can come up > with a way to do it easily, ok, but it's not an avenue worth spending too > much time on. > The idea of splitting the world, as the slides do, into three basic camps (liberal democracy with good traffic analysis, liberal democracy with bad traffic analysis and horrible dangerous places) is simply not serious. The idea that our liberal democracies do perfect traffic analysis and so we should ensure *everyone* including *non-NSA* attackers can do it for *free* is just bizarre to me. It is incorrect as a conclusion to do nothing because some people somewhere *may* be good at traffic analysis. The logic of the slides suggest that raising the cost from a kid-in-a-cafe to NSA is proof that we shouldn't bother. Again, the security nihilism monster appears. We should reject this nihilism and fix the problem. Encrypted SNI makes sense as it makes traffic analysis harder. Encrypting DNS queries makes sense too. Composing it with other systems may or may not make sense. Even when TLS is composed with a tool to do traffic analysis resistance, the exit node of the TA-resistance network can still do selective attacks based on SNI. In that case the DNS is likely to be resolved at a different exit point. Thus if we want to punt again and say, hey, traffic analysis resistance is better left to Tor or something else, please consider that plaintext selectors make Tor's job harder. These changes make it more expensive and in some cases, it will stop attackers who would otherwise be able to make an attack happen undetected. It requires an attacker to spend more money on CPU, memory and on other resources to do correlation across multiple collection points. Kicking the can down the road doesn't even begin to summarize why leaving SNI unencrypted is incorrect. Metadata is a serious problem and reducing it whenever possible (eg: we won't fix TCP/IP on the IETF TLS list), even in liberal democracies, helps to solve the problems we face from mass surveillance. All the best, Jacob From nobody Wed Dec 2 19:49:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB20E1B2C51 for ; Wed, 2 Dec 2015 19:49:03 -0800 (PST) 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] 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 DmqhETtykLNk for ; Wed, 2 Dec 2015 19:49:03 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E5E1B2C2E for ; Wed, 2 Dec 2015 19:49:03 -0800 (PST) Received: by igcto18 with SMTP id to18so3398653igc.0 for ; Wed, 02 Dec 2015 19:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NmsVBEOp41LCixL3L5CYBKvNxraZU0OsdFuJvAl+Osk=; b=zaWnXE8j5Ovcp4pMrpFVdX9Zk4sOGJuo5PKssSU1G+0jHK+isPSlvUS1B7nnw3FGaS 2mJqJz6O26i5XLqMGh1SfzwZYMrv6ROwuoFdMn0ZJbEU0Ed4BGRuHkIysw3x+mwVl429 HRVobjFGg7KhbmDHZijsSS9Z8J9da6GHuliJSIDQEiziDtY71lvKivBPIwapjIMFBk3q qzooah5Epvo+lCKz/wNHezwqT+azTQk7nnwfK6TVj+zxRn3uNsVUdZIs31i7EMP0maJC TGKiHuNzr9CIGO/RlXvKyi1tKX/UNQpLP3HzJd/ZEHWiQR5SwAEQgqLan+Ab2u2RPvlC bQtg== 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=NmsVBEOp41LCixL3L5CYBKvNxraZU0OsdFuJvAl+Osk=; b=Vw4PX6jSt6vpzlDY3ojicPGmW3SHH7ACEtjiZCzD97Sn8NAz0w9/0+lryjwMBKg3JB 188LwWUtz7qJe/2MBJYWDCiGJHoiZOEjCvw1dwbITBJQyurCdMJIqh3kVdwPrxVvNLzQ zYpb4KpXVpnNt9GmfLHAyElr2C9u+zITXkZi7U6M1PDe+UA5L4oVswoLD6BAyfa5nXDb /2HlyBTvFVnK2FPQWK2+v8jg/ReQcXg4/BwWmf8jbcKqacU4DgiG2RBubN06jba85uSj PyZQWqGnww4RiKHrxuHubpHRItYavWUPnCxXmIcE5pdFKHv27iq/Ltosbdlc0Q974U7B bsUw== X-Gm-Message-State: ALoCoQmqt7sYcxWfYKyVZb4d34OUtUtXKYs72vCxbWVhc0M5ahXLbsAamA9FH3FuUBF9EmaYlrBX MIME-Version: 1.0 X-Received: by 10.50.225.1 with SMTP id rg1mr16802335igc.78.1449114542587; Wed, 02 Dec 2015 19:49:02 -0800 (PST) Received: by 10.79.70.71 with HTTP; Wed, 2 Dec 2015 19:49:02 -0800 (PST) X-Originating-IP: [46.188.10.23] In-Reply-To: <60e21928e9174d8ea7eb84b00ad85884@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <1b5cf52ca90e45bd82f5247ca675dead@usma1ex-dag1mb1.msg.corp.akamai.com> <60e21928e9174d8ea7eb84b00ad85884@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Thu, 3 Dec 2015 03:49:02 +0000 Message-ID: From: Jacob Appelbaum To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 03:49:04 -0000 On 12/3/15, Salz, Rich wrote: >> It provides protection. Specifically it provides confidentially. > > It is far from clear that the privacy gains anything in the form of > practical protection. Having looked at it, I'm unconvinced. And I've been > a privacy/crypto advocate for a very very long time. > I resolve DNS through Tor and so in that case, my TLS connections often exit over a different circuit. My TLS connection would not otherwise leak the host I'm requesting if the protocol had a way to protect that data. It doesn't. The protocol leak is the problem. All the best, Jacob From nobody Wed Dec 2 19:49:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E42A1B2C79 for ; Wed, 2 Dec 2015 19:49:22 -0800 (PST) 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 Q-6rt9l3-7sj for ; Wed, 2 Dec 2015 19:49:20 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5861F1B2C2E for ; Wed, 2 Dec 2015 19:49:20 -0800 (PST) Received: by igcph11 with SMTP id ph11so3056622igc.1 for ; Wed, 02 Dec 2015 19:49:19 -0800 (PST) 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=N5z29g9oHvIPB8CAcHONZIywfk6bcohN4zNZ5Ck13gk=; b=tAU4+DWdqM47pWaTxdJcwKeMGpwxAK4fD+cuMzU7ed9Br6sf3SJBYABGbTdb2jEpau zkXv31tI1ZQBYP+5e/1X7+qQU4rAmGywz5ujBtcuHUZ7X5FxRC0pVtxQrhNQxFg8Iu/Q 1/PnGnmElrxDTxq5kegOt6TLJHxtzZOf4H6vd21Vv2GlULn8qh+Lqutzn50m9STIFGDm 1ry9zSdjA/ZZcZuM2YWfLm/vmoweokHChMQva9SCmczm+82EiymZ6922X5xyDvGBD24i VAVMUMksqQ8/eCScLeJrNVs9OFm92KoT2S9WWHqEHuLmV2ApALv9DG+MdryYGsSACjcd YDyg== MIME-Version: 1.0 X-Received: by 10.50.30.6 with SMTP id o6mr37921937igh.94.1449114559784; Wed, 02 Dec 2015 19:49:19 -0800 (PST) Received: by 10.36.155.139 with HTTP; Wed, 2 Dec 2015 19:49:19 -0800 (PST) In-Reply-To: References: <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <201512021513.49894.davemgarrett@gmail.com> Date: Thu, 3 Dec 2015 14:49:19 +1100 Message-ID: From: Martin Thomson To: Jacob Appelbaum Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 03:49:22 -0000 There are a lot of inaccuracies in that presentation, so I wouldn't pin too much on it. In any case, before we all get too excited about this, there are some solutions, I've seen a write-up of one of them, but it was a little hard to follow first time around. Some of the things that are described as impossible aren't that hard to fix. On the flip site, it doesn't provide a fully general solution. Expect to see something very soon. Until then, I don't think that an in-depth on what isn't even at a straw-man level of detail is that helpful. We need details before we can say whether the cost-benefit makes sense. On 3 December 2015 at 14:38, Jacob Appelbaum wrote: > On 12/2/15, Dave Garrett wrote: >> On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote: >>> Encrypted SNI doesn't give you the kind of protection you think that it >>> does. We (me and a colleague) did a pretty thorough analysis that showed >>> this. It was not a conclusion we expected, or wanted, to reach. It was >>> presented at the TLS Interim before the IETF in Toronto. Slides should be >>> online. (For example, the adversary will know the IP address or might not >>> care about false positives, etc.) >> >> URL from Rich's previous email citing this: >> https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view >> > > I've read these slides. I'm... at a bit of a loss. The entire slide > deck seems so flippant as to be not worth addressing. It just doesn't > even pass the giggle test. > > Though upon reading it, I am struck by two core points: > > One is that big companies will be pressured by governments. > Ironically, Akamai isn't one of those as they're willingly in bed with > governments around the world. But I guess as the slides say, the > author isn't speaking on behalf of Akamai. That said - good, I want > governments to have to go to a company rather than to the user - the > company may have a legal team, the user may have hidden or otherwise > protected themselves. Hopefully the company is in a position to do > nothing or will take action to protect the user's basic liberties. > > The second is a constant security nihilism. Yeah, a lot of stuff is > broken - so lets acknowledge it bit by bit and then fix it all. > > I would encourage everyone to read the slides as the conclusion in the > presentation simply do not follow. If I had been in the audience when > they were presented, I would have been at the microphone objecting. > The idea that this convinced anyone is baffling. > > It is clear that privacy concerns exist in many many different > protocols and that many protocols need to be fixed. Many people point > at other protocols as a way to punt on the issue for their own > protocol. The cycle continues and the privacy violations continue > without end. > >> Please don't brush this argument off in favor of the "obvious" answer that >> encrypted SNI is helpful. The sad truth is that it's a lot of effort with a >> lot of risk for virtually no gain. I was quite in favor of encrypted SNI >> before reading it, and I had to concede the point after. If we can come up >> with a way to do it easily, ok, but it's not an avenue worth spending too >> much time on. >> > > The idea of splitting the world, as the slides do, into three basic > camps (liberal democracy with good traffic analysis, liberal democracy > with bad traffic analysis and horrible dangerous places) is simply not > serious. The idea that our liberal democracies do perfect traffic > analysis and so we should ensure *everyone* including *non-NSA* > attackers can do it for *free* is just bizarre to me. It is incorrect > as a conclusion to do nothing because some people somewhere *may* be > good at traffic analysis. The logic of the slides suggest that raising > the cost from a kid-in-a-cafe to NSA is proof that we shouldn't > bother. Again, the security nihilism monster appears. We should reject > this nihilism and fix the problem. > > Encrypted SNI makes sense as it makes traffic analysis harder. > Encrypting DNS queries makes sense too. Composing it with other > systems may or may not make sense. Even when TLS is composed with a > tool to do traffic analysis resistance, the exit node of the > TA-resistance network can still do selective attacks based on SNI. In > that case the DNS is likely to be resolved at a different exit point. > Thus if we want to punt again and say, hey, traffic analysis > resistance is better left to Tor or something else, please consider > that plaintext selectors make Tor's job harder. > > These changes make it more expensive and in some cases, it will stop > attackers who would otherwise be able to make an attack happen > undetected. It requires an attacker to spend more money on CPU, memory > and on other resources to do correlation across multiple collection > points. > > Kicking the can down the road doesn't even begin to summarize why > leaving SNI unencrypted is incorrect. Metadata is a serious problem > and reducing it whenever possible (eg: we won't fix TCP/IP on the IETF > TLS list), even in liberal democracies, helps to solve the problems we > face from mass surveillance. > > All the best, > Jacob > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Dec 2 19:56:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686CA1B2CBB for ; Wed, 2 Dec 2015 19:56:31 -0800 (PST) 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] 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 HR_L-i-JK7kK for ; Wed, 2 Dec 2015 19:56:29 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC44B1B2EEC for ; Wed, 2 Dec 2015 19:56:21 -0800 (PST) Received: by iofh3 with SMTP id h3so68735609iof.3 for ; Wed, 02 Dec 2015 19:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u7/rcVpWTRrBILiO3wbfzi75MxLyi5Sv+CMm96J4PJw=; b=wuVZZS4+BPn2xnoMkJrn0TjlzWZ0oR3dxAGDXaDBi+jU38AWVNhNWWQvydpkuBlOYz 8A9oxXjI0ObhXjnA63q88hGbqUow7fiv04a0W3qdsGwc/1GOAhHWtF8WBMLFbz3v7A9j DcKytZloM1UKFHecRFW9tnxQxBbbLd8WF9SOteHV7J8xnKKi2lzLz9orVFHdrC89Blc3 roLzEpZA9+JIbSPkMB7l7Q4sMH4D94hSsLfqsa7S/CR22yHocMuHD0qgncHGL7fgnpek HwgmeGfNHOrMrUDCmt0Aw9elg+3aXkRxU0wDV5lFbBHwANdekzAlpwkap+1SAqZkkUGt Twiw== 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=u7/rcVpWTRrBILiO3wbfzi75MxLyi5Sv+CMm96J4PJw=; b=VaBL/WaP/mubfVyZe5pIyRJVHRZkb4SKKgUk91792VNPxHy7cE/UVzPnoNKtwEh5HW HgM01oDMOb+v8wznl7qRmDAjTuAexq8Nya+RWXXeCnHuaDrbHfN64HJOZ9a45YUuRLsP C0dMZtZYk0NaS9uBLHfnzujJqntLUivTRICcYc8U9U6LCeHCF2VgQTshdo8aBKFOnqh5 a0Zz4LcX526KcF4sz69kB2iv6qjsAvE2H4TNThwKQCa3+bSNSzK6DxR3UsHeWk4w+iQr GQx5DwD3WcAJprlv2InO2AOMH0z3QS/OCGeRQfPuk6CebAi/qmfUn4O8zVePxdkB+J7C fS5w== X-Gm-Message-State: ALoCoQny1jycXphxh30Ot/DOaM0OD4DDqxOL1TtxFHSY4s0y0i1Gz+16CCsJqlqPkC5S8F/MWgSA MIME-Version: 1.0 X-Received: by 10.107.7.210 with SMTP id g79mr6782192ioi.81.1449114981137; Wed, 02 Dec 2015 19:56:21 -0800 (PST) Received: by 10.79.70.71 with HTTP; Wed, 2 Dec 2015 19:56:20 -0800 (PST) X-Originating-IP: [197.231.221.211] In-Reply-To: References: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <1b5cf52ca90e45bd82f5247ca675dead@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Thu, 3 Dec 2015 03:56:20 +0000 Message-ID: From: Jacob Appelbaum To: Eric Mill Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 03:56:31 -0000 On 12/3/15, Eric Mill wrote: > On Wed, Dec 2, 2015 at 7:52 PM, Jacob Appelbaum > wrote: > >> On 12/2/15, Salz, Rich wrote: >> >> it seems blindingly obvious to me that we want it >> > >> > Few things, particularly in the security arena, are blindingly obvious. >> If >> > it actually provides no true protection, then it's just as bad as the >> > security theater in US airports. >> >> It provides protection. Specifically it provides confidentially. >> >> It doesn't solve the fact that the DNS is a privacy violating >> nightmare. It doesn't change the fact that the NSA breaks the rules. >> > > And what Don and Rich's analysis is trying to isolate is how much real > protection you get from that level of confidentiality, so that a decision > that weighs all available factors can be made, including the complexity > cost. I'm sorry but that analysis is just not a serious and rigorous analysis. > It's not just a collective action problem because DNS isn't encrypted too. The conclusion summary is that because there are many problems, we won't address our part of the problems. The conclusion is that SNI privacy isn't worth it because those who live in liberal democracies with poor traffic analysis, well they just don't matter much. Which is... just... well, as I said above, I just don't take this seriously. > Their analysis also looks at what you get when both are encrypted. And > regardless of DNS being encrypted, rainbow-table style reverse lookups of > IP to DNS name are always possible. That doesn't mean encrypted SNI isn't > worth it -- it clearly provides a security attribute (confidentiality) to > an important piece of information. You're now suggesting an attacker that computes rainbow-tables to arrive a possibility which in itself sounds like a massive improvement over what was an absolute certainty. > But it's not enough to drive ahead and say that some attribute outweighs > every other consideration. For example, HSTS' persistence of memory can be > abused as a tracking device: > > http://zyan.scripts.mit.edu/sniffly/ > > And this was known at the time the spec was finalized: > > https://tools.ietf.org/html/rfc6797#section-14.9 > > But HSTS creates security benefits that are well worth the cost of that > tracking potential (which can also be mitigated through preloading). There > are a lot of browsers and communities which use and advocate for HSTS that > might generally balk at creating tracking devices. > Yes, tracking with HSTS is a problem and there is work being done to mitigate that tracking concern. > I'm not advocating a strong stance on whether encrypted SNI is worth > pursuing, or whether TLS record headers should be encrypted in TLS 1.3. But > it's useful to keep the debate framed in its full context, rather than > narrowing it to a black-and-white discussion over whether a generally good > attribute is good or not. Sure and that full context includes RFC 7258: "Pervasive Monitoring Is an Attack" - something that defines reasonably clearly many of the concerns I've stated. All the best, Jacob From nobody Wed Dec 2 20:02:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516D11B2F70 for ; Wed, 2 Dec 2015 20:02:00 -0800 (PST) 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] 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 8w6zpNtg3I38 for ; Wed, 2 Dec 2015 20:01:59 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689D81B2F5F for ; Wed, 2 Dec 2015 20:01:59 -0800 (PST) Received: by igcmv3 with SMTP id mv3so4872449igc.0 for ; Wed, 02 Dec 2015 20:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B8RQPKo80ZYJuEw5Ibesl8PHViHy0+F+xRrtE0UCdZE=; b=H9RhPpHhStI0ONEFmJ6iZOrdng9+3/KBuUudbFt+9gioEIIeqQ/52ZfKGO5i/o98jI /QAJeL6WhvjY0SoiIdPlbqmTsUnA2PLAZVAKDfv7sFiQQL36MNiZrpc43u5XGM6S7ZJo SfF2VeKHFjPBq/b1qB3dJU4EV2vNOl/5a80+WQEw6W/l1YGu4tmzfOg+jA2Sz0l/degO fJx+dBBKOZmx+kSAAhFSV1mABSlbN79mrp+CujxjLo3h5m+NtgHQ6QUPusHLjL0cHhGL 06Jkh/5JVL8VFb4DzmiUSo9+4YE94+iz4kX69GIwCyJEPtwu3OSw+SCE+c4p5GsDnp6l cb0w== 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=B8RQPKo80ZYJuEw5Ibesl8PHViHy0+F+xRrtE0UCdZE=; b=AXVkilkhoWDcbpeHWpadS//PNUQqGOr2zVist+6KksDGCKTVUcxibarPhagzqV+jke PrChD4ZmaeD3wVBiw5cq+XSrL8G37gzbSJfXQBx+dDzPim1FSVRho05JztNbu9jVPUTI U5dYa91Ol1d5IDXJGgsHTPO56mItTMkT4MsBPgScQeGJErNA4E3qKHXRUQG2F6S/l9AV M0+yKXSSWuSeSl2os04tqV1XO5+JHeKnBhsdoF2Q7m4mSjzkSUZ2s8Cl5AKLn8RDfA+2 YGMGP7qIUqF8Dr2BU/I81P0iQCdKI4EYBeOL17JYf2O+fYaCIvUMGG0cAiU5eWjb+qFn Z4Ug== X-Gm-Message-State: ALoCoQn85PqJJRtHjK9s+BCSaFbTAtFoxU1J2Fu1rrZ+umfTJDe/cbsMdDkyNOXXvMAYhX9sUpH3 MIME-Version: 1.0 X-Received: by 10.50.59.242 with SMTP id c18mr10543929igr.82.1449115318777; Wed, 02 Dec 2015 20:01:58 -0800 (PST) Received: by 10.79.70.71 with HTTP; Wed, 2 Dec 2015 20:01:58 -0800 (PST) X-Originating-IP: [197.231.221.211] In-Reply-To: References: <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <201512021513.49894.davemgarrett@gmail.com> Date: Thu, 3 Dec 2015 04:01:58 +0000 Message-ID: From: Jacob Appelbaum To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 04:02:00 -0000 On 12/3/15, Martin Thomson wrote: > There are a lot of inaccuracies in that presentation, so I wouldn't > pin too much on it. > I'm not pinning too much on it and I was surprised by the amount it was suggested would win me over. I actually went in thinking that I'd be crushed and concede; imagine my surprise! > In any case, before we all get too excited about this, there are some > solutions, I've seen a write-up of one of them, but it was a little > hard to follow first time around. Some of the things that are > described as impossible aren't that hard to fix. On the flip site, it > doesn't provide a fully general solution. The question up for debate seems to be if we should bother and I think that yes, we should bother. I spent some time today thinking about solutions for encrypting not only SNI but also other headers. It isn't entirely clear how to solve this problem in a few cases - but especially in the case of a repeated visit or a site that has an HSTS entry, I can see a few ways to protect the information. > > Expect to see something very soon. Until then, I don't think that an > in-depth on what isn't even at a straw-man level of detail is that > helpful. We need details before we can say whether the cost-benefit > makes sense. Where is the design actually happening? I know a few cryptographers who are interested in the design process. All the best, Jacob From nobody Wed Dec 2 20:33:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748BC1B300D for ; Wed, 2 Dec 2015 20:33:46 -0800 (PST) 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 pvqmFYBdwtXh for ; Wed, 2 Dec 2015 20:33:45 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F021B300B for ; Wed, 2 Dec 2015 20:33:44 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C7C06284E35; Thu, 3 Dec 2015 04:33:43 +0000 (UTC) Date: Thu, 3 Dec 2015 04:33:43 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151203043343.GD18315@mournblade.imrryr.org> References: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <1b5cf52ca90e45bd82f5247ca675dead@usma1ex-dag1mb1.msg.corp.akamai.com> <60e21928e9174d8ea7eb84b00ad85884@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? 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, 03 Dec 2015 04:33:46 -0000 On Thu, Dec 03, 2015 at 03:49:02AM +0000, Jacob Appelbaum wrote: > > It is far from clear that the privacy gains anything in the form of > > practical protection. Having looked at it, I'm unconvinced. And I've been > > a privacy/crypto advocate for a very very long time. > > I resolve DNS through Tor and so in that case, my TLS connections > often exit over a different circuit. My TLS connection would not > otherwise leak the host I'm requesting if the protocol had a way to > protect that data. It doesn't. The protocol leak is the problem. The most compelling argument for SNI encryption I took away from this thread the cheap opportunity for blocking traffic based on cleartext SNI. Of course SNI encryption can't help if the destination IP address supports one or a very few related domains, but it could help otherwise. Of course nation-states willing to play hardball will work-around the problem, but they are doing that even without encrypted SNI. [ Those of you on the crypto list will have seen the announcement about Kazakhstan mandating a national security certificate which must be installed on all customer devices that use the Internet... ] -- Viktor. From nobody Thu Dec 3 00:50:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8F81B32CA for ; Thu, 3 Dec 2015 00:50:13 -0800 (PST) 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 jWGMmgvXJdWL for ; Thu, 3 Dec 2015 00:50:11 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF8291A1BDD for ; Thu, 3 Dec 2015 00:50:10 -0800 (PST) Received: by wmuu63 with SMTP id u63so11444058wmu.0 for ; Thu, 03 Dec 2015 00:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=xMGInjA5CwnGqBrH+EJdrzPP8qDZSW3Na0krpczpaDU=; b=Hi325vi2YNZZnrLjJnLFA6pa9z7gYTYxIDQNCLQnYBI5V3RzTStlZILcWPZRzg8yea BSVuHifNuLAj4d47pEOpFbtJT2hPDFxaCQG1U+WdSbn18mBty4dfxsSDJlWw3J7Mob1k Ln566XVTlZVJ9r5IqX5O8GsGCZyiUORmFKFCjAfn1MHTwsHuWJaimRW8ps62BiIdFLnL pHNCRGYfstm035A0KmUViZhHLDOQbye4d5Jh4xkKYokhzmrN/ZYsANtMJnqJsoMIn16Z 0orGTCq+j6ojGsYIMboM9UVarFO+TfFJHrN8jWPwVyzweYuC0GBCtoxowcuTRbU54o74 HdCQ== X-Received: by 10.194.249.97 with SMTP id yt1mr10127970wjc.89.1449132609270; Thu, 03 Dec 2015 00:50:09 -0800 (PST) Received: from tsf-476-wpa-0-180.epfl.ch (tsf-476-wpa-0-180.epfl.ch. [128.179.176.180]) by smtp.gmail.com with ESMTPSA id jt9sm6535380wjc.24.2015.12.03.00.50.07 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Dec 2015 00:50:07 -0800 (PST) To: tls@ietf.org References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> <9BFA68AB-9677-4BE7-8F5E-D1A66EF95BA5@gmail.com> From: Bryan A Ford X-Enigmail-Draft-Status: N1110 Message-ID: <56600243.2010308@gmail.com> Date: Thu, 3 Dec 2015 09:50:11 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070900040107050009020609" Archived-At: Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 08:50:13 -0000 This is a cryptographically signed message in MIME format. --------------ms070900040107050009020609 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/2/15 4:45 PM, Watson Ladd wrote: > On Wed, Dec 2, 2015 at 10:34 AM, Jacob Appelbaum = wrote: >> On 12/2/15, Eric Rescorla wrote: >>> It's not really clear to me what the anti-traffic-analysis benefit of= your >>> proposal >>> is over and above just padding everything to a fixed size. That's cer= tainly >>> far >>> easier for the implementation to do, especially in typical stacks whe= re the >>> application just calls SSL_Write (or whatever) and so there's no obvi= ous >>> API point to provide the "next length", so as a practical matter the = stack >>> will very often if not always be in "last block" mode. >>> >> >> I think that it eliminates all static distinguisher in the protocol >> for all data covered by the encryption. That is a fantastically >> wonderful benefit. >=20 > What's a "static distinguisher"? Padding solves this problem as well, > but it also solves problems resulting from TCP segmentation down the > stack, which header encryption doesn't. What does header encryption > offer that padding does not? Once again (for the n'th time in this thread): Padding is great and we should encourage implementations to do it, but it may be impractical to mandate (a) that *every* TLS 1.3 implementation use padding all the time, and (b) that *every* implementation that does use padding uses the *same* padded record size as every other TLS implementation. If TLS 1.3 did mandate that all implementations always pad to the same standard-defined record length (to echo Viktor Dukhovni, GO ATM! GO ATM! :) ), then it might be arguably the case that encrypting headers wouldn't add any further benefit. But short of that, encrypting TLS headers makes it strictly harder for a passive adversary - or an active adversary who can only inject but not block traffic - to distinguish between padded or unpadded TLS 1.3 streams, or to distinguish between TLS 1.3 streams padded to different block sizes. In particular, with encrypted records, we get a guarantee that nothing in the transmitted TCP stream content itself leaks information about the internal pattern of records, even if it's un-padded or differently padded from other streams. The attacker has to use other side-channels to perform such distinguishing attacks, and other side-channels are often lower-bandwidth (e.g., the total length of whole streams or bursts rather than individual records), and/or more noisy (e.g., the lengths and timings of TCP segments, which may get retimed and/or resegmented by all sorts of activities both at the endpoints and in the network). B >=20 > Sincerely, > Watson >=20 --------------ms070900040107050009020609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwMzA4NTAxMVowLwYJKoZIhvcNAQkEMSIEIEGo2AVaqxzDXClO5TsPSeZx7bKaOZOPlNoH EuDwEhL1MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBAJTsiFwsIHMvCROt bcR5dY0OlK0XFsxbuSN8Q0Kk+tiGvLiW8oePld2aDr9DDpSJi39dZsbpo8Z8nxWC3IiT4p7R OmJmb6Lh4PTMSUbuGppyB9r6CUUs1h7AineN7yyUkFcn4ThqFfVunbkFHPhxlwfBUWwNPl+c Vbs5twBGRekKRxXMQZF/L4U3tIyt+iPVr2Ii2xl1leROIPkiCRfnWUfgmFmUSICIsUySlbEc k4p5SwCWOf47YuAasoNwaKtbqoSo3CtJnJLTD/FU3t61E743T27ZjTJNtc9EvI+muSUK+Jqz bjkC9yF2ZC9zlrjawndVXYiXalop8u7pa7JlmYQAAAAAAAA= --------------ms070900040107050009020609-- From nobody Thu Dec 3 01:29:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5901A877B for ; Thu, 3 Dec 2015 01:29:15 -0800 (PST) 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 A-0fzCol7nYb for ; Thu, 3 Dec 2015 01:29:14 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71DA81A8733 for ; Thu, 3 Dec 2015 01:29:13 -0800 (PST) Received: by wmec201 with SMTP id c201so13644831wme.1 for ; Thu, 03 Dec 2015 01:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=td9yEVkC4ZD5uNOxXLG3iT44md2/5BQqbsicByFcoms=; b=rdlglDM5iSYPweIP9gurqWZ8Ylese7lYTfD3gMvRo41ryUXvjgzofU7tpPNf66sr47 Fc3rt5a7biIZrRtyfloy1/mb6WZ7Uulat6sn3dIhTvz+5SLtrlE2eSwnf9Y2k4K5rAWZ VzrkW5qYgwRFjkI+dPH1GuQJdUE6XYqRy0q2wXjk13uAPlaySCjGo0euQGMn2zqJ7Bk8 +Yql2SoEYM5yqLlavqgwZPcs/OL1B/5G5CN+NqYhLraT9pxRA++eKvc7FKmk4NHonPWs 6kzr8qjjg0abmgp1LQ8pYXrfQMCTpRvCxUmR0XO/yBVkf4yXEDoMHbQXhcxl1Meg/ICD ETBg== X-Received: by 10.28.182.134 with SMTP id g128mr51305691wmf.95.1449134952062; Thu, 03 Dec 2015 01:29:12 -0800 (PST) Received: from tsf-476-wpa-0-180.epfl.ch (tsf-476-wpa-0-180.epfl.ch. [128.179.176.180]) by smtp.gmail.com with ESMTPSA id uq3sm6633706wjc.10.2015.12.03.01.29.10 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Dec 2015 01:29:10 -0800 (PST) To: tls@ietf.org References: <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <201512021513.49894.davemgarrett@gmail.com> From: Bryan A Ford X-Enigmail-Draft-Status: N1110 Message-ID: <56600B68.9060908@gmail.com> Date: Thu, 3 Dec 2015 10:29:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <201512021513.49894.davemgarrett@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090709040007080005060005" Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 09:29:15 -0000 This is a cryptographically signed message in MIME format. --------------ms090709040007080005060005 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/2/15 9:13 PM, Dave Garrett wrote: > On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote: >> Encrypted SNI doesn't give you the kind of protection you think that i= t does. We (me and a colleague) did a pretty thorough analysis that show= ed this. It was not a conclusion we expected, or wanted, to reach. It = was presented at the TLS Interim before the IETF in Toronto. Slides shou= ld be online. (For example, the adversary will know the IP address or mi= ght not care about false positives, etc.) >=20 > URL from Rich's previous email citing this: > https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view >=20 > Please don't brush this argument off in favor of the "obvious" answer t= hat encrypted SNI is helpful. The sad truth is that it's a lot of effort = with a lot of risk for virtually no gain. I was quite in favor of encrypt= ed SNI before reading it, and I had to concede the point after. If we can= come up with a way to do it easily, ok, but it's not an avenue worth spe= nding too much time on. I find it darkly amusing that this argument against the usefulness of encrypted SNI, supported in substantial part by an argument that "1st world eavesdroppers do TA really well", is being brought up in the context of a discussion of my proposal to make traffic analysis harder by encrypting TLS record headers (in combination with other useful techniques such as padding). By all means, let's not encrypt SNI because traffic analysis is easy, and let's not make traffic analysis harder because SNI is unencrypted anyway! ... or something like that. :/ I completely agree with Jake's arguments against security nihilism. The fact that we can't completely and perfectly solve the whole problem all at once should not prevent us from working on little pieces of the problem bit by bit and making life incrementally harder for at least some of the wide diversity of adversaries out there. B >=20 >=20 > Dave >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------ms090709040007080005060005 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwMzA5MjkxMlowLwYJKoZIhvcNAQkEMSIEIIDo4Kyfwt6+kgC8hLqYwivAoovnQgpncAmU +nMtpygDMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBABZwe2+9BVlerVQI ru7Z1ZN526NUqmkN8sILcu9k8bGE5DhejIPnlja74FbXuUDbzQpk6E8zwd9vVAY63dBqS4y+ z0cuev4VYKoenbFb8e711CosY+U0Tl2mZWZXdTCRpfnXfGepZ+vafOrt8zG5UJP3uXIIw0XU 0hMp0w+gYr88y2HCzpsCcK5fLYbAcRHc9Gk6g8+9xeBFuYt9qm6CCdsi7mmSSjR95UelED5m LWX62ApraP3w4jiy218wRXm+W01d6GruTtNvqXO2ce5SExhM95s+5F+Uy5bedrSWk31pHIWe rKsPDCHKYL0F7bdUQN18GcHtt3NxpHfWH91FHZ4AAAAAAAA= --------------ms090709040007080005060005-- From nobody Thu Dec 3 01:35:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA22E1ACE18 for ; Thu, 3 Dec 2015 01:35:33 -0800 (PST) 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 S28FMqFAXGvp for ; Thu, 3 Dec 2015 01:35:30 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9958B1A1BE4 for ; Thu, 3 Dec 2015 01:35:29 -0800 (PST) Received: by wmww144 with SMTP id w144so13876615wmw.0 for ; Thu, 03 Dec 2015 01:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=IiRuNABfIAHPIbuVAduwbojcsE8Uzk4YrSW5TvZ/lrE=; b=SMJk0AHVfa2CoxSPHHMT/Hf5EP6dXbJqiXpwz+zBKwC+BEam3GjGMOH09jIIZlEa1M +xk8+XuLuaZsJxt8hIk8HjiS9jnDgMRU6k3Y5wFae774F+ub2vQRGuVGG6H1eFXhss/W v954cXrdEADuZIGrvv9RDK13mjpz+CZUy6TLl1JKUoZaujadqMTEu44AjvMqwvAUSPIo PaTBFPsN95XmvkWRc9ECbxeoj9Pp+I6cUO143xIWZueY1DQyw6NmX28DceD9kDNefS+l cJ6g6oj41LBUnyg33KU46axK246AZFojfRDFZH3woRYNbpwHDelw8axXe4otRVoRPy+L Ehzw== X-Received: by 10.194.62.14 with SMTP id u14mr10153253wjr.24.1449135328229; Thu, 03 Dec 2015 01:35:28 -0800 (PST) Received: from tsf-476-wpa-0-180.epfl.ch (tsf-476-wpa-0-180.epfl.ch. [128.179.176.180]) by smtp.gmail.com with ESMTPSA id kb5sm6661440wjc.20.2015.12.03.01.35.26 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Dec 2015 01:35:27 -0800 (PST) To: tls@ietf.org References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <3B906BDF-CA30-4EDF-ADA9-ABFC2A25014D@gmail.com> From: Bryan A Ford Message-ID: <56600CE2.2060807@gmail.com> Date: Thu, 3 Dec 2015 10:35:30 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040805010304000306030900" Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 09:35:33 -0000 This is a cryptographically signed message in MIME format. --------------ms040805010304000306030900 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mike, On 12/2/15 4:14 PM, Mike Copley wrote: > [...] Not sure if this is the right place to consider, but would DTLS 1= =2E3(?) be able to encrypt headers and still handle packet loss and re-or= dering? If DTLS needs cleartext headers, would it be better to advise one= approach for both protocols? Please see the other recent E-mails in this discussion thread specifically addressing how my first proposal extends to DTLS. My second proposed approach to header encryption is admittedly more TCP-specific, and that might be one legitimate reason to prefer the first one if we care about keeping TLS and DTLS as closely-aligned as possible. B >=20 > Regards, >=20 > Mike Copley > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------ms040805010304000306030900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwMzA5MzUzMFowLwYJKoZIhvcNAQkEMSIEIB1YTevWEnZpaq0xkQl29sV34KaJOuNZFXzv TFLKGgx4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBAHJbnmEYL4JEa+K4 mmwuDg9XLo657NFocSxFaTbe5c1XO4qHUgNRB0vpzdnHV0UR9PfgRPI0vWwTfHX6iaEi0lBA iV+PFWBSFd6GcXhA+aArhf0IwwzEFk8pb7/hVaqPZEFE0+yUYkFbKp2aq/fScedqrupYshPm wMfMOQonrzpo5BvRKn3BHk/yPKLCgAwXiiJBKTFtCG+LEIIVkrpewTF7pO6/ThDMcpIAmvCr LALmSVXfSV7iQGZRhMmQT5hfDbzija6b/FlMAFpyCA3mw0GXuLlZcKGjm05UGMBTZ08vXiZn r4WFE4ezYVGNzE/Ir4hWpFY4q23YFfwcM5Z5TeIAAAAAAAA= --------------ms040805010304000306030900-- From nobody Thu Dec 3 01:51:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F051A1BCC for ; Thu, 3 Dec 2015 01:51:26 -0800 (PST) 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 4hOD4CFkon4G for ; Thu, 3 Dec 2015 01:51:24 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89981A1B95 for ; Thu, 3 Dec 2015 01:51:23 -0800 (PST) Received: by wmvv187 with SMTP id v187so18355400wmv.1 for ; Thu, 03 Dec 2015 01:51:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=zK9+YFrtarjYbPKIS1nO5r3HbZpD28k162cafu6S1PA=; b=Iz6KsMKlRYivEnDNv79q76iobHM+PaG9Ee4EVVjWJ14C7D7VmhiMFBFIFlcPbw0K39 K3ZFCrN3O0lptW8+0dyubcv50OPhifbIsc357ubSUbAKJn5jRTM1y/Y7CeInZghsK+zb 7QucXSe86hc4uw6oXOhmRI9NTqLdtJTwbuv9iKgv+JjuO4lu3/0WsnruxxpwrCGk/jlN jzHhoF+VQSy6LCzvUc2vNHc1EcigKJSJwhhP7QQa/qmFWZdt559yX8GKWeB3PaW5ljWa GciasggMDD8lEwHSnnppOOLnshgMDfYJTVtBRFhVFmGhGzqtdZZwBhW0dQ4OctS2GhaB i6+Q== X-Received: by 10.28.72.137 with SMTP id v131mr51473664wma.63.1449136282316; Thu, 03 Dec 2015 01:51:22 -0800 (PST) Received: from tsf-476-wpa-0-180.epfl.ch (tsf-476-wpa-0-180.epfl.ch. [128.179.176.180]) by smtp.gmail.com with ESMTPSA id an7sm6712908wjc.44.2015.12.03.01.51.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Dec 2015 01:51:20 -0800 (PST) To: "GUBALLA, JENS (JENS)" , Fabrice Gautier References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <547EE95EB794FD4DB8062F7A4C86D0BC4A39F163@FR712WXCHMBA13.zeu.alcatel-lucent.com> From: Bryan A Ford X-Enigmail-Draft-Status: N1110 Message-ID: <5660109C.7070803@gmail.com> Date: Thu, 3 Dec 2015 10:51:24 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <547EE95EB794FD4DB8062F7A4C86D0BC4A39F163@FR712WXCHMBA13.zeu.alcatel-lucent.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040303040002020403080607" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 09:51:26 -0000 This is a cryptographically signed message in MIME format. --------------ms040303040002020403080607 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Jens, On 12/2/15 11:47 AM, GUBALLA, JENS (JENS) wrote: >> Fortunately the solution is fairly simple: the receiver simply pre- >> computes and keeps in a small hash table the encrypted sequence number= s >> of all packets with sequence numbers between H-W and H+W, where H is >> the highest sequence number correctly received so far (the horizon) an= d >> W is the anti-replay window size as specified in 4.1.2.5 of RFC 4347, >> which typically should be 32 or 64 according to the RFC. The receiver= >> can precompute all these encryptions because in my proposal TLS header= s >> are encrypted with a stream cipher (or the AEAD operating as a stream >> cipher), so it's just a matter of producing the correct cipherstream >> bytes and XORing them with the uint48 sequence number. >> >> Whenever the receiver gets a datagram, it looks up the encrypted >> sequence number in the hash table, drops it on the floor if it's not >> present, and if it's present the receiver gets the decrypted sequence >> number from the hash table and uses that in the AEAD decryption and >> integrity-check. In the low-probability event of a hash-table >> collision (i.e., two uint48 sequence numbers encrypting to the same 48= - >> bit ciphertext in a single 129-datagram window), the receiver can >> trial-decrypt with both (or all) sequence numbers in that colliding >> hash table entry. Or the receiver can keep it even simpler and just >> drop all but one colliding entry, introducing a pretty low probability= >> of introducing occasional "false packet drops." >> >> The hash table is pretty trivial to maintain efficiently as well: e.g.= , >> whenever the horizon H moves forward by delta D, remove the first D >> entries from the current window and precompute another D encrypted >> sequence numbers (where D will most often be 1). In the simple design= >> that doesn't bother dealing with hash table collisions (e.g., that >> allows each hash table entry to contain only one value), perhaps don't= >> even bother clearing/removing old entries; just gradually overwrite >> them with new ones as H moves forward. >=20 > [JG] In case there is a packet loss of at least W subsequent DTLS recor= ds:=20 > How can the receiver then ever adjust its hash table? Wouldn't that mea= n=20 > that no records at all would be accepted anymore? Excellent question - I had intended to discuss that in my original post but in the end forgot to include it. Indeed, with this approach as it stands, if every packet within a full window of W consecutive packets fails to reach the receiver, then the receiver has no way to resynchronize and the connection will simply fail. In congestion-controlled protocols like TCP (or DCCP) that do exponential backoff when they detect many consecutive losses, the protocol may be more likely simply to hard-timeout than to reach the W-packet resynchronization limit. But admittedly many UDP-based protocols aren't (or are rather weakly) congestion-controlled, so this may be more of a problem for them. It's probably the case that the "forward-looking window" should be allowed to have a different value from the "backward-looking window", and perhaps the "forward-looking window" should depend on RTT (e.g., measured maximum packets-in-flight). However, one way to eliminate this risk of permanent desynchronization, at the cost of a bit more complexity in the receiver implementation (though this needn't affect the protocol spec at all) is for the receiver's "forward-looking window" to consist not of W consecutive sequence numbers but a sparse set of sequence numbers at exponentially-increasing distances. For example, if H is the current highest sequence number, include in the forward-looking cache the encrypted sequence numbers of the sequence number of the next multiple of 2^1 beyond H, the next multiple of 2^2, etc., for as many multiples of powers-of-two to get sufficiently far out in the sequence number space where we're convinced there's no realistic chance of a run of total or near-total packet loss unless it really means the connection is dead anyway. :) Again, these are all considerations that need not affect the protocol but could be tuned by implementations (perhaps with some recommendations in the protocol spec). But regardless, all of this is just to make the case that header encryption is in principle just as feasible in DTLS as in TLS, and using fairly similar techniques; right now I think we should keep the main focus on whether to do it (at least) in TLS, for which is seems pretty easy to do it in at least two different ways I've proposed. B --------------ms040303040002020403080607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwMzA5NTEyNFowLwYJKoZIhvcNAQkEMSIEIBbNj5sXNTZbLFYgaHR7M2irP476Kx7zMx4O f9rFjZ8lMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBAF+zI2YfdMsLAwRh Vz0pRy9APXvtXAPRXkjiYIoaw7B0MuLXKO10Ox/MDPxO/7vxG5n3i7MjG2nMorTOC9rPV1E/ C7C+Wf7pyGR2bqQz8G9OkWIGBNchS8fWXTHax31EDlaIn/4Ig2AoHtW87QNOelVB9b4dKOCu OVXyt0Cq+kGGbdYuZPR6Spu0SksD03+DCJQZQgis/IAMBGEJwadoIEFywhh5+Mm0UJ4uBGal Dy7KfCFVzZRn/HnIgIviblp33Th0d9iyDrBfVukvBo9pmyAEMrOV+SqaETkezGLzgFHbSLRr lhDnkXvV/1A0sZ2AzSwFH9WiALqUk4Ncwuk2nisAAAAAAAA= --------------ms040303040002020403080607-- From nobody Thu Dec 3 03:36:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30531B33D4 for ; Thu, 3 Dec 2015 03:36:46 -0800 (PST) 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_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6] 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 B5bXhibPWAZj for ; Thu, 3 Dec 2015 03:36:42 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 433C21A884B for ; Thu, 3 Dec 2015 03:36:42 -0800 (PST) Received: by igcmv3 with SMTP id mv3so10846511igc.0 for ; Thu, 03 Dec 2015 03:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lOIBJkHWTIsN/ISeuVRdbgHfpNRMmiUSXW79q3OgQck=; b=ka6CS7YpebaJuEIYHzKCSn/XrtpxDMH9KveU36kIIaYumtZElB6UwfSNMoG/ucHnMX DrCCmoXNE3Lz9DEvAtkVyiUn2TkIwg0LjUsIsPE3SU3FeTnhDJ+EXPoXhiOR2ESmsPtf ZOml18xTv7fhM1htdzO/GHh6OONDdMOhXiRag8Ixw01DZgydfOnC29h8XBEszeAR/PUO bTffMfP9a7XsYOHFF3i2nLam6JSqQF6a5F6K5ZYJNZpslPe/BeE4fFQZPLqcxSdlYPgb aDXBrFZiq+897aONtfDCjQZxZuYFviZesmjZxgjvNs/5jWdOZg1898r3NpoYdkPvNias +6Xw== 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=lOIBJkHWTIsN/ISeuVRdbgHfpNRMmiUSXW79q3OgQck=; b=EdENe5mO7E8sqnmid3YUGp5Sy8OQpM0L0tR0NssHZyQkWPUnB8V24c+zcGWFDnDu7y 3fvU1nwmCXff9su8tNzsJ5WrtIUgjpWcuSZtM3kXfkcNhRDukk0Qtk6PKSFDlYBuT1Ii y5sd/61uNqSYhgrXQ7sIbV3yWFtv3mF6zbShXBlrcQ9OQmDZW9Lpjj63sfD6HzgMZ5H9 sCD6/6bxnqklhbKvISCnjY5tL9i3UFhFL9/cSgup524p7N+coty8oltsyvIGgQz3jX71 TSeNp2vHdeaKZNW8cxrtF98LoXjtISxzzmxzziulb5wvSPtG1LdnvEg1Ka7QfGZM2oPs 4t4Q== X-Gm-Message-State: ALoCoQmLcguOS1v5OdQygKBQes3Lo0JSD+aLM8bVG9K19rnfjWl436EFyVpp624Bs17ITuZHTAqI MIME-Version: 1.0 X-Received: by 10.50.143.12 with SMTP id sa12mr5931181igb.82.1449142601490; Thu, 03 Dec 2015 03:36:41 -0800 (PST) Received: by 10.79.70.71 with HTTP; Thu, 3 Dec 2015 03:36:40 -0800 (PST) X-Originating-IP: [193.171.202.150] In-Reply-To: References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> <9BFA68AB-9677-4BE7-8F5E-D1A66EF95BA5@gmail.com> Date: Thu, 3 Dec 2015 11:36:40 +0000 Message-ID: From: Jacob Appelbaum To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 11:36:47 -0000 On 12/2/15, Eric Rescorla wrote: > On Wed, Dec 2, 2015 at 7:34 AM, Jacob Appelbaum > wrote: > >> On 12/2/15, Eric Rescorla wrote: >> > On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford >> wrote: >> > >> >> On 02 Dec 2015, at 06:02, Martin Thomson >> >> wrote: >> >> > On 1 December 2015 at 08:22, Bryan A Ford >> >> > wrote: >> >> >> The 2-byte length field in each record's header no longer indicate= s >> >> >> the length of the *current* record but instead indicates the lengt= h >> of >> >> >> the *next* record. >> >> > >> >> > Ensuring that you know the length of the *next* record is difficult >> >> > and could dramatically degrade latency, or adding extra bogus >> >> > padding >> >> > or extra bogus records. For instance, I can always send in bursts >> >> > of >> >> > two packets, a one octet packet that promises the remainder of the >> >> > burst and one that promises a single octet packet. At that point, = I >> >> > get to do what I've always done and you have gained little other >> >> > than >> >> > an increase in packet size of around 19 octets (best case). >> >> >> >> That type of inefficiency is extremely easy to avoid; please read the >> >> rest >> >> of my proposal where I discussed exactly that at length. Yes, a >> >> particularly stupid implementation could send everything in bursts of >> two >> >> packets, but it=E2=80=99s ridiculously easy for a slightly smarter >> implementation >> >> to avoid doing that. And what you=E2=80=99ve gained is complete encr= yption >> >> and >> >> integrity-checking of the whole TLS record before any part is >> >> interpreted, >> >> which seems like a nontrivial security improvement. >> > >> > >> > It's not really clear to me what the anti-traffic-analysis benefit of >> your >> > proposal >> > is over and above just padding everything to a fixed size. That's >> certainly >> > far >> > easier for the implementation to do, especially in typical stacks wher= e >> the >> > application just calls SSL_Write (or whatever) and so there's no >> > obvious >> > API point to provide the "next length", so as a practical matter the >> stack >> > will very often if not always be in "last block" mode. >> > >> >> I think that it eliminates all static distinguisher in the protocol >> for all data covered by the encryption. That is a fantastically >> wonderful benefit. > > > Wouldn't that benefit be equally achieved by simply padding all records > to a fixed length? You could do this with no protocol change and, as I > said, it's far easier for the implementation. > Padding is potentially useful but has two issues that come to mind which are both non-issues in most cases. The first is the economic cost for extra bytes and the second is the security of the padding scheme. Padding strategies are a complement super encryption but probably not a replacement. Padding protects against one set of attackers (bean counters) and super encryption provides confidentiality against another set of attackers (GPA/APA). >> > [0] This issue doesn't apply to DTLS because the stack will just move >> onto >> > the next UDP datagram. >> >> An off-path attacker can't do much with DTLS, if designed correctly. >> Especially if they only see some packets - they'd only get the UDP >> headers and then the rest should be uniformly distributed random data, >> no? > > > DTLS records do in fact contain a length field because it's possible to > pack >1 record into a single UDP datagram. In practice, I think that > most stacks do 1:1 except perhaps during the handshake. They also > contain a sequence number to aid in reconstruction (important > in this case because TLS 1.3 uses the sequence number to > form the AEAD nonce). > > However, as you suggest, an attacker can't DoS DTLS connections by > injecting a small number of packets because the DTLS stack will just > reject bogus packets. This alone makes me think that DTLS with encrypted record headers is going to be a killer feature. Especially if an implementation rotates over ip:port and keeps sessions open even as clients move between networks. We'll hopefully see clients keyex on one network and keep a session open as they move to another network. That would make interception or attacking that client very difficult for an off-path partial view attacker, as well as very difficult even for a fully on-path mitm. The downside is that it won't compose very well with existing anonymity systems. The other other upside is that those systems can use this mode in the future for client -> network, inter network communication and network -> everywhere communications. All the best, Jacob From nobody Thu Dec 3 05:15:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F9D1A702A for ; Thu, 3 Dec 2015 05:15:25 -0800 (PST) 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] 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 lh3c9EnG0jZv for ; Thu, 3 Dec 2015 05:15:20 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0379C1A7023 for ; Thu, 3 Dec 2015 05:15:20 -0800 (PST) Received: by lfaz4 with SMTP id z4so90220372lfa.0 for ; Thu, 03 Dec 2015 05:15:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=XtZ0P4XRzTlL5auVhJk4A1HwYwQiXk6H1YIdbHY8pLg=; b=ZzF5VJN2JF18JO2ctaVqWMDgox5i3VAQIB4jr1Xk3sbSS9vGb6N0jvKF4BPG2IKIjW MansaZiEt29cmrvEuf7UzumZiUIi+RyD6HZstWL6s6P/V/HNQAjuSsm4jV+Y2PweExeI SFJyiENGVpGSl5xb7g349Sxx6gGoeiA5/DPII= 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; bh=XtZ0P4XRzTlL5auVhJk4A1HwYwQiXk6H1YIdbHY8pLg=; b=DZV/v6VluHKgn/m7QL/zqlZc/M9uK7CzROJaqH7/EpPlULrj3c8OEkmSrDYZaRS2Yt 5I3+2u2L+B6r06x8BN4eF8G69bh91LR09f7wgFyNbVe/5xgwZr1Dsaf3c0+8aQkKLSm2 lf8hri4VIuzCUOEgfXYIrh1m0DHNIsE7w7fRdJEtHelYR+NXduhpMxOyxALWmJVElFPJ +8EtjhrPPAbZ5a1oZXgj/mZYvPWnIgtUASXXbbVwVWwHE0hlLjw+suz0tgFDqWLNreXS /IrBoUi7Osq6D3RdsVoXigpaP0Hvk209bTJwrecs4XhyhN6bWfaYMRJBMxmZbvRop3TE XJJg== X-Gm-Message-State: ALoCoQmUD3inYBhV3TdaRKiYU6zPdlXtYJjfbXic7t2ZJ+ll4Bye6YZCIcr2yQdbC47mW+jlncIf X-Received: by 10.25.145.81 with SMTP id t78mr5754726lfd.86.1449148518073; Thu, 03 Dec 2015 05:15:18 -0800 (PST) Received: from [192.168.1.103] ([41.232.113.177]) by smtp.gmail.com with ESMTPSA id qp7sm1378793lbc.24.2015.12.03.05.15.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Dec 2015 05:15:16 -0800 (PST) Message-ID: <5660405E.3060008@azet.org> Date: Thu, 03 Dec 2015 14:15:10 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Jacob Appelbaum References: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <1b5cf52ca90e45bd82f5247ca675dead@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig586AE4E4C5EEA8093952812D" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 13:15:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig586AE4E4C5EEA8093952812D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi *, Jacob Appelbaum wrote: > I'm sorry but that analysis is just not a serious and rigorous analysis= =2E No it's not. It's a very short presentation from a TLS-WG interim meeting. The threat-model concerns Akamai's (and other's) current and - possibly - future use of TLS. We're not trying to build an Onion routing protocol. Given the FUD on the Tor dev list, this is a good thing. While the presentation might have flaws from the perspective of an Onion routing protocol developer, it reflects the point of view of a lot of people/companies on this list, I assume. >=20 >> It's not just a collective action problem because DNS isn't encrypted = too. >=20 > The conclusion summary is that because there are many problems, we > won't address our part of the problems. The conclusion is that SNI > privacy isn't worth it because those who live in liberal democracies > with poor traffic analysis, well they just don't matter much. Which > is... just... well, as I said above, I just don't take this seriously. See above, different point of views on the same problem. I agree here and think we should continue to find a proper solution for encrypted-SNI for TLS 1.3 - if at all possible. What we currently have on our hands is not very convincing to me. >=20 >> Their analysis also looks at what you get when both are encrypted. And= >> regardless of DNS being encrypted, rainbow-table style reverse lookups= of >> IP to DNS name are always possible. That doesn't mean encrypted SNI is= n't >> worth it -- it clearly provides a security attribute (confidentiality)= to >> an important piece of information. >=20 > You're now suggesting an attacker that computes rainbow-tables to > arrive a possibility which in itself sounds like a massive improvement > over what was an absolute certainty. +1. >=20 >> I'm not advocating a strong stance on whether encrypted SNI is worth >> pursuing, or whether TLS record headers should be encrypted in TLS 1.3= =2E But >> it's useful to keep the debate framed in its full context, rather than= >> narrowing it to a black-and-white discussion over whether a generally = good >> attribute is good or not. >=20 > Sure and that full context includes RFC 7258: "Pervasive Monitoring Is > an Attack" - something that defines reasonably clearly many of the > concerns I've stated. >=20 While kind of a political/policy document I agree that IETF WG's should follow (and participants read) it. I remember the STRINT meeting in 2014 where a lot of people were very pissed about NSA activity and we decided we want to do something about it. If it takes a standard a few months longer to be finished, please give it the proper amount of time for enough people to put their ideas into it. Most people do not come up with solid engineering solutions over night. And crypto is hard as we all know. We should not forget that TLS has a very different threat-model and performance assumptions than Tor though. Thanks, Aaron --------------enig586AE4E4C5EEA8093952812D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWYEBfAAoJEOTbZJL9ubXVIKYQAJ9joZ6V2ZvTRg/pUTPGI3rp jEk52h2CoXeGVFc88WgPzvyqdEiwSTVllF09jiY3UB9/ozAArCPgFgusHtqRfTdh mXFHEitzgO0PwvzUFL5MdfQh95vj1Tsqzp5piwaIX/oZN1Itf3YhW1xpIcaNQ+Ey 844D/XDW+i0jIbgYzivIBk5/J5z9P8nvsLXUm8yLThWyTwMcJCrjOaQiYoeMO6bg PizpmqKUB89xVXN85i2r0/pU8blWuaWsmj/KAkd04RfD8ggCeuTjCRXmnx9K0NRu dniiUW9VoFzRArU8afV8knZWgtXafWFjQIjwCaAbNwchdShKbt9z+ftbQAHh6x4X n6aUThy9x099l5TsR/OKqAq9Yiy7gCQoqu58madijtaySET61ePsfu42x/068cpm 6CucXmHFh8Zqz8ZQqPHosDzxmai3YoNgc+U7Re/Q9ISAMZDzd+zNNrI0Ff3mWS+Y FoIg1p+RZ9i4MFjjdiHJnk1ZPG2sxDBeOvWfTp+q0TNhOP28K/UzH61YV6ck06lE Y6tiYDAmYsc21jJgAjQmGtJIWBt+glQRJih0xWa4s72I2bgwtJYMGQio2hBGY0Rm mFwlJILpMAuIH+s2EGBBpQLBClUTqAWnTqjPOFFxB/w5WXF+Q77fwuuXFNtqsWLi cJrjP/YEd83xqczkNZXb =VNsf -----END PGP SIGNATURE----- --------------enig586AE4E4C5EEA8093952812D-- From nobody Thu Dec 3 05:22:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5041A86F0 for ; Thu, 3 Dec 2015 05:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 oHWpWXR6pIky for ; Thu, 3 Dec 2015 05:22:36 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id E19BE1A86EB for ; Thu, 3 Dec 2015 05:22:35 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3DBEA200008; Thu, 3 Dec 2015 13:22:35 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 27C34200007; Thu, 3 Dec 2015 13:22:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1449148955; bh=ctaVK1t6l7wKgHWui1A2NExxg+9+UGSRjiKn5xv5eRs=; l=291; h=From:To:CC:Date:References:In-Reply-To:From; b=liU8INnLv0u0VEGrSZzBxKWNS4PlALZUx6CsP+UPzgsdtOYxdEQNapwtB0KS5snZR Euspml3XqlHR99UJpnFpkJyIeqq7hkLBgxC7TnwePjta3nu6mzzbmtQfpgCth58pFB BTnZ//Vi+qRFlMH3sI8GgIjz6aSCL9Iw1FXw1z44= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 0E9EC1E08A; Thu, 3 Dec 2015 13:22:35 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 3 Dec 2015 08:22:34 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Thu, 3 Dec 2015 08:22:34 -0500 From: "Salz, Rich" To: Jacob Appelbaum Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all? Thread-Index: AQHRLX2dhp3T1Pv4DESd4yQecOlihJ6494wAgABIcjA= Date: Thu, 3 Dec 2015 13:22:33 +0000 Message-ID: <393ab34a3001483f8c2bd9666d6f80e7@usma1ex-dag1mb1.msg.corp.akamai.com> References: <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <201512021513.49894.davemgarrett@gmail.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: [172.19.32.157] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 13:22:37 -0000 > I actually went in thinking that I'd be crushed and concede; imagine my s= urprise! The fact that you viewed it as "crushed and concede" implies to me that you= r mind was already made up, and that no description of trade-offs was going= to sway you. Is that belief unfair to you? From nobody Thu Dec 3 06:08:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36F61A884C for ; Thu, 3 Dec 2015 06:08:01 -0800 (PST) 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] 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 3I770jgU38O7 for ; Thu, 3 Dec 2015 06:08:00 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F52F1A885D for ; Thu, 3 Dec 2015 06:07:53 -0800 (PST) Received: by lbblt2 with SMTP id lt2so2223402lbb.3 for ; Thu, 03 Dec 2015 06:07:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=1jRqhBPtk/Z4J/7M032lh5mesZwKsyBCaDsmCwZfT4g=; b=O5Qr7Cx0SLDCp3J7rwFK0oqZkRWF1evPMlYIwA6Dck76oJ7KG6t8tX3NtiQIIbY5qo iM73+ybXXqJeQtVsFJabBcKKuIOmX4JEO8bi79MB6DNHPvF71DxbXc0pkUQyBwho2PzO CzpdU8lZeWO9n3OcFMIm2wU0Gkd1OZ2lrCGrQ= 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; bh=1jRqhBPtk/Z4J/7M032lh5mesZwKsyBCaDsmCwZfT4g=; b=lUOMVaHdTvKx1HHZBCqghzs+GA12oE2reEjvNk/nI5FOek7NNh6yReWIEDPbuDaexR PLobVC+JtBFh2Ns8d37OKXMaodT2328URmlmdM5h6BPEf5i81mynJrQTt42AMEukxIyK ioKUYwqPcGtY5n9Z7GVZUunciSPhqROu0rWGwgmV1TXAsmOOMfZGm23fdNJNERo85Wci YHzhvNcOrZ48Ty95ZfIFh2GZvdII8uKTkE59IaxzIaHfVeFWba+c1jUBWOrL1yFOBW/f YQRYJ6N1d5fsuCgdQH6EFMWvd7NmV9G8i8zuiEYaz6sYQmeZYIdR5K70Y5JeCvCeGgw/ Yw2w== X-Gm-Message-State: ALoCoQkOTDm1hgUWjKFXP37Fq4XmPeLMc4KRBLbA921odl5000O15yxocFzByDjoPE2zC4qI3Eya X-Received: by 10.112.180.35 with SMTP id dl3mr5729690lbc.27.1449151671378; Thu, 03 Dec 2015 06:07:51 -0800 (PST) Received: from [192.168.1.103] ([41.232.113.177]) by smtp.gmail.com with ESMTPSA id m64sm1413801lfd.45.2015.12.03.06.07.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Dec 2015 06:07:49 -0800 (PST) Message-ID: <56604CAF.5000305@azet.org> Date: Thu, 03 Dec 2015 15:07:43 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Jacob Appelbaum References: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <1b5cf52ca90e45bd82f5247ca675dead@usma1ex-dag1mb1.msg.corp.akamai.com> <5660405E.3060008@azet.org> In-Reply-To: <5660405E.3060008@azet.org> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig1FA06C24F62748E58F3EC6FA" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 14:08:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1FA06C24F62748E58F3EC6FA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable PS: Aaron Zauner wrote: > No it's not. It's a very short presentation from a TLS-WG interim > meeting. The threat-model concerns Akamai's (and other's) current and -= > possibly - future use of TLS. We're not trying to build an Onion routin= g > protocol. Given the FUD on the Tor dev list, this is a good thing. Whil= e > the presentation might have flaws from the perspective of an Onion > routing protocol developer, it reflects the point of view of a lot of > people/companies on this list, I assume. >=20 I don't think traffic analysis is in the treat model for TLS proper. If we wanted to circumvent traffic analysis we'd have to introduce noise and randomness (Pond does a good job there using Tor and other mechanisms). I don't see how we can engineer a low-latency (now even 0-RTT) network security protocol that will do that in a performant manner. When time comes and people have 10-40-100GE at home, maybe. Infiniband would be nice. But that will still leave out use for 3rd world countries (which still run on XP anyway). This is a technical list and we should keep politics and FUD aside as best as possible. Greetings from a very empty Sinai peninsula, (A)aron --------------enig1FA06C24F62748E58F3EC6FA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWYEywAAoJEOTbZJL9ubXV3pUP/3Zf7+xl89OPTbDmhHcox0Sc UoB1LKe3BlIu3bXsShRIEI6iIzq5D+oxZURQKf5bL+P3Tev7+y8VDv6z4kNXd1Z9 6wXAMyaqyMRwXW86M9I2zPxHAmRuDlaJN50CEcQQrofjR/4+c8Y8SRhejDnBWdMt 7Z8kv11P5B/cDrsvM0Y6W0i0uoBfZSdxxRL0Sv7svkTnYucHySaudzRch+23DT2f G7INBLBgTDTjxAdsTUILL4vVpzTiQbwixSxMzIzVnMZLz3u/MqAEQ+/uzjnrA76Z ncYxsUFXzH2ephxRykgJ7y4ofUS/dt3bqAerwV8bJFdZngNPTxGGxkZ+OL8k+Cv5 PgujKN1Ew+mfZvoZ7jAPkBeX1QUPjpQho/LHEL+qqOYesgO1am1yzpdQteKtcKD1 zSBrfzExsiAA6kQySS2JZvMX5FvEHImjvs0+Ue+7M8dXJ9p/Ad2AEig1xX6iwoW4 lcT+DxVy3xAnerXmzV/SNa+A0nB+NG6v2rTIlWgzoKtL/o89TwRt/uY9Lmq7E7ZI /H4WB8Rs0zGDLscNkoDKKoU3uD+8KFJcjH/PVHRDNN1r6vDUES39f2UqkOwp3ANU e8B9v+kzWfiQXlfOdQleQTmvIt/BQ7waKF9DIGcnPv9yFUX0CVMwZvY1+2ANqohu 3uBOP7kvE9F/FTlvay7q =uInd -----END PGP SIGNATURE----- --------------enig1FA06C24F62748E58F3EC6FA-- From nobody Thu Dec 3 07:24:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEC91A8A09 for ; Thu, 3 Dec 2015 07:24:58 -0800 (PST) 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] 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 fOkovMTjSMZB for ; Thu, 3 Dec 2015 07:24:57 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5158B1A8A43 for ; Thu, 3 Dec 2015 07:24:57 -0800 (PST) Received: by ioc74 with SMTP id 74so84081800ioc.2 for ; Thu, 03 Dec 2015 07:24:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0XJtKl4qbmXgYAxrnv4w7G9H0hhoRz/1zI7VggHsxQo=; b=mW+WA4KZDTHhv6yykf4uRib2BPxpLjdPEZ+jY2BrIS4oJFkXcblpAQMmrmHcjMUakF 4dX2o0L3NGsk+UWP3pC1522HDu00/ZeeIa//8nhFV9uBIymTYz7PKDxRi49VTw3uNh8b 46N+4akbgOxDi+O6OCtDitXBVoJ0HMwI1Ru8aXeVYfMk9MWZiLqsc7dYfF+W6+cEobm6 G5FlAj44c85/qAy5wH64J/JJlMy+dbv2HjC7HZQLoXJOdF1wU9+RzmlQasIGbJ+wdqFJ gWjn65RpdBs/xOMmIi7yNLoLchAO8CPPnP3bFZ4LkZ4ypB9M63aFLOTkATRefArSveu9 6lhg== 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=0XJtKl4qbmXgYAxrnv4w7G9H0hhoRz/1zI7VggHsxQo=; b=fyQaBmJwgRRBLcMC7lX4bSalWeVd3wQBO6/2HfeHrxXNX4Zua4nJd+2OqC08f+riu4 g8AIJkSkpdpXCzfSuEVwg9P+2+u5ijOwdz/h+jcTS1TvhJk/i5RhkY1o9ewiSDjqtjxz ZsxKV39B21qDuhqoO2yW0XNzBS/tkteMCT85SAoRTZigKuqjtp+S7v4mQjJUraeF1bk1 0PgtOUaJkvgvax6s92y41nB/fXCEA0DqxYe7caMcB4VSB38t/LsVpf3emwB+c01xrimJ 61qv6PriovmIMvADMrd0oVDxBVuTFIPRmQ95sLiV0PQ3k/N8rsy2qRGMtu2SA8u3DoPX 5rbw== X-Gm-Message-State: ALoCoQnOOWwq1PJUpfkszN7kDrRKNYwQ5JEN2Yt8eA5DkV2XeofNYvmcSe1vTVrtiv1TPvc/abfu MIME-Version: 1.0 X-Received: by 10.107.137.19 with SMTP id l19mr8307676iod.138.1449156296547; Thu, 03 Dec 2015 07:24:56 -0800 (PST) Received: by 10.79.70.71 with HTTP; Thu, 3 Dec 2015 07:24:56 -0800 (PST) X-Originating-IP: [89.248.169.36] In-Reply-To: <393ab34a3001483f8c2bd9666d6f80e7@usma1ex-dag1mb1.msg.corp.akamai.com> References: <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <201512021513.49894.davemgarrett@gmail.com> <393ab34a3001483f8c2bd9666d6f80e7@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Thu, 3 Dec 2015 15:24:56 +0000 Message-ID: From: Jacob Appelbaum To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 15:24:58 -0000 On 12/3/15, Salz, Rich wrote: >> I actually went in thinking that I'd be crushed and concede; imagine my >> surprise! > > The fact that you viewed it as "crushed and concede" implies to me that your > mind was already made up, and that no description of trade-offs was going to > sway you. Is that belief unfair to you? No, I said explicitly the opposite: I expected that you would change my mind because you took the time to think about it, write slides and present it. I'm late to the party, so I had an open mind and was shocked that this was what had convinced anyone at all. I'm sympathetic to the government pressure angle but I do not believe that because one is afraid, one does better by preemptively capitulating. If Akamai wants to leave their users insecure, I look forward to another CDN offering privacy options. Such choice is missing if that isn't an option and it isn't on as a strong default. In any case, I await the specific cryptographic details and some of the people in my cryptographic research group (non-Tor) are interested. When it is published, I'll see if it actually helps to solve the problem at hand. If we can't design a cryptographic scheme to protect SNI, I'd understand fully why we won't have such a protection deployed. If we design it and then we're unhappy about DNS, well, great, one problem down - next up, dnsop works to solve the DNS query privacy problem. There is already work being done there - so I think we're on the way. All the best, Jacob From nobody Thu Dec 3 08:00:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3898F1A014C for ; Thu, 3 Dec 2015 08:00:00 -0800 (PST) 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 v9DMmDQsMWXq for ; Thu, 3 Dec 2015 07:59:58 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4E91A0145 for ; Thu, 3 Dec 2015 07:59:58 -0800 (PST) Received: by ykba77 with SMTP id a77so90453272ykb.2 for ; Thu, 03 Dec 2015 07:59:57 -0800 (PST) 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=iAUq6ouFXIurJtQJGYa6jjITe/8Mr04nQ+RWEEYk84A=; b=VrnN70cakwy0CCLuS+jKrTphUUtlPYVBKluimecPV0ynEQfIyPCXXW/Su02ik15aJA sswE7QTwCwLH3kh3ZmlAEoI+mb11sLl5NZgdWRjepe52UO4aGuKagTfn1K+9gPpujU7+ 15v14aUjzjcfKoudAWus7ALw7PX3NX720JbC86n7q+5pAwGtGe7MDZ/iu6phHqkLdqwA j3lrdll+EkYoBr3d9eOm5G+2DCV6FkJqtp1BEd2pcFV4PGH72tzsz1y0lpeK4GsjT07D BPK9YHrK3MrwhdnDSEcfCP8wgdZKjLwK/xh4yPFGjVrUcbVZ0EuBnCaQeRO13fnr5Qsg zSJw== MIME-Version: 1.0 X-Received: by 10.129.98.133 with SMTP id w127mr7438003ywb.239.1449158397834; Thu, 03 Dec 2015 07:59:57 -0800 (PST) Received: by 10.129.148.131 with HTTP; Thu, 3 Dec 2015 07:59:57 -0800 (PST) In-Reply-To: References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> <9BFA68AB-9677-4BE7-8F5E-D1A66EF95BA5@gmail.com> Date: Thu, 3 Dec 2015 10:59:57 -0500 Message-ID: From: Watson Ladd To: Jacob Appelbaum Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 16:00:00 -0000 On Thu, Dec 3, 2015 at 6:36 AM, Jacob Appelbaum wrote= : > On 12/2/15, Eric Rescorla wrote: >> On Wed, Dec 2, 2015 at 7:34 AM, Jacob Appelbaum >> wrote: >> >>> On 12/2/15, Eric Rescorla wrote: >>> > On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford >>> wrote: >>> > >>> >> On 02 Dec 2015, at 06:02, Martin Thomson >>> >> wrote: >>> >> > On 1 December 2015 at 08:22, Bryan A Ford >>> >> > wrote: >>> >> >> The 2-byte length field in each record's header no longer indicat= es >>> >> >> the length of the *current* record but instead indicates the leng= th >>> of >>> >> >> the *next* record. >>> >> > >>> >> > Ensuring that you know the length of the *next* record is difficul= t >>> >> > and could dramatically degrade latency, or adding extra bogus >>> >> > padding >>> >> > or extra bogus records. For instance, I can always send in bursts >>> >> > of >>> >> > two packets, a one octet packet that promises the remainder of the >>> >> > burst and one that promises a single octet packet. At that point,= I >>> >> > get to do what I've always done and you have gained little other >>> >> > than >>> >> > an increase in packet size of around 19 octets (best case). >>> >> >>> >> That type of inefficiency is extremely easy to avoid; please read th= e >>> >> rest >>> >> of my proposal where I discussed exactly that at length. Yes, a >>> >> particularly stupid implementation could send everything in bursts o= f >>> two >>> >> packets, but it=E2=80=99s ridiculously easy for a slightly smarter >>> implementation >>> >> to avoid doing that. And what you=E2=80=99ve gained is complete enc= ryption >>> >> and >>> >> integrity-checking of the whole TLS record before any part is >>> >> interpreted, >>> >> which seems like a nontrivial security improvement. >>> > >>> > >>> > It's not really clear to me what the anti-traffic-analysis benefit of >>> your >>> > proposal >>> > is over and above just padding everything to a fixed size. That's >>> certainly >>> > far >>> > easier for the implementation to do, especially in typical stacks whe= re >>> the >>> > application just calls SSL_Write (or whatever) and so there's no >>> > obvious >>> > API point to provide the "next length", so as a practical matter the >>> stack >>> > will very often if not always be in "last block" mode. >>> > >>> >>> I think that it eliminates all static distinguisher in the protocol >>> for all data covered by the encryption. That is a fantastically >>> wonderful benefit. >> >> >> Wouldn't that benefit be equally achieved by simply padding all records >> to a fixed length? You could do this with no protocol change and, as I >> said, it's far easier for the implementation. >> > > Padding is potentially useful but has two issues that come to mind > which are both non-issues in most cases. The first is the economic > cost for extra bytes and the second is the security of the padding > scheme. > > Padding strategies are a complement super encryption but probably not > a replacement. Padding protects against one set of attackers (bean > counters) and super encryption provides confidentiality against > another set of attackers (GPA/APA). But as several people have noted, encrypting record lengths doesn't actually protect the lengths of the records as well as you think it does. Timing packets is not some exotic and unavailable technology. I don't understand what attacks padding and introduction of dummy packets doesn't defend against that encryption of record lengths does. Sincerely, Watson From nobody Thu Dec 3 08:04:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29A81A8F3D for ; Thu, 3 Dec 2015 08:04:40 -0800 (PST) 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] 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 jLYSrZpg9hKx for ; Thu, 3 Dec 2015 08:04:39 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D511A8BC0 for ; Thu, 3 Dec 2015 08:04:34 -0800 (PST) Received: by ioir85 with SMTP id r85so85711301ioi.1 for ; Thu, 03 Dec 2015 08:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dK1WRk1qq4OkiHHEh7utaFQ/ytOqmXSdpyRsYU7HsGE=; b=h0TR/WbpCyxP/zroIv6UnZ6ZU0sGnmj74ot8vMCEh2RUTNWxZiiWAWCjRhSmPOfqU1 RrHbUtRnEdD9YCvaDfGwuuSWiJo2l9VfUpR48TifNchXXyOpG3P9zobCHg51onKyHnJS W1WMUF6L4QikAirk+dTaNVat6C1Cs9KuGP89tIS9BByYHmAT1DSh2IOsNEXvl06aGN5V 06w1K82XLFz/VebDRxhQZToBPy3Lz0f4JGE6jupJfI/m81/gXHZT1k+3sueyTFy03Sti eqdTU0njqFRDxMsNF03Qd6hZM+B9YIXHvEc059B/4sJqFlIcuZfAgrXS2CRe9/GYjLvt j7pw== 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=dK1WRk1qq4OkiHHEh7utaFQ/ytOqmXSdpyRsYU7HsGE=; b=PimAqqrOq8eGot+6/IievzJY/0F8lJyxEEKhugVAM5eurBcreGN6tptOeoJVfLvyH8 dIUSYOrC3sAb/j5gScuXMLX0MHW7Eb6npLLHaemxldJozRcYs44VjTkvjLhXuMQTiuAN S0mRtY76qn6ggm7aoQNnL3NsTdf9PBNEgh8cLGpOgxHZ2LR95i2ClFCKF9t3wEzf7prn WyfpCGF9Xrw2qL86naM75RMFbRE+cEBJ7UEl3ozoOCp8mBEafg/yRWiS2C3Xru8sxyYh egrRJRhsTCh9ev0wK21s+TlRRhJiybbeeXCPD+7dTd5v+XUVIq+MT0Q+uYBMcpb8lUBF I2Jg== X-Gm-Message-State: ALoCoQlIcaY2aKEWcQESyIMMos1Bd0ys1aHUquq9WUqQbH68s+/zogEJ33/+OL9zF9M81+j+bJue MIME-Version: 1.0 X-Received: by 10.107.138.28 with SMTP id m28mr11277756iod.24.1449158674250; Thu, 03 Dec 2015 08:04:34 -0800 (PST) Received: by 10.79.70.71 with HTTP; Thu, 3 Dec 2015 08:04:33 -0800 (PST) X-Originating-IP: [185.10.71.107] In-Reply-To: <56604CAF.5000305@azet.org> References: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <1b5cf52ca90e45bd82f5247ca675dead@usma1ex-dag1mb1.msg.corp.akamai.com> <5660405E.3060008@azet.org> <56604CAF.5000305@azet.org> Date: Thu, 3 Dec 2015 16:04:33 +0000 Message-ID: From: Jacob Appelbaum To: Aaron Zauner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 16:04:40 -0000 Hello, On 12/3/15, Aaron Zauner wrote: > PS: > > Aaron Zauner wrote: >> No it's not. It's a very short presentation from a TLS-WG interim >> meeting. The threat-model concerns Akamai's (and other's) current and - >> possibly - future use of TLS. We're not trying to build an Onion routing >> protocol. Given the FUD on the Tor dev list, this is a good thing. While >> the presentation might have flaws from the perspective of an Onion >> routing protocol developer, it reflects the point of view of a lot of >> people/companies on this list, I assume. >> > > I don't think traffic analysis is in the treat model for TLS proper. I'm confused by what you mean by traffic analysis. We encrypt content in TLS because we know that we want confidentiality. We want that because we know people do basic traffic analysis looking for sensitive data in plaintext. There are many kinds of traffic analysis adversaries. I think TLS isn't trying to beat a global active adversary, for example, while also providing anonymity. It seems that TLS is trying to beat a global passive adversary from violating the confidentiality of the protocol. A lack of confidentiality in many cases allows for attackers to do better traffic analysis and selective denial of service attacks. Failure to deal with very simple traffic analysis leads to much more serious attack vectors being actively exploited in the wild. > If > we wanted to circumvent traffic analysis we'd have to introduce noise > and randomness (Pond does a good job there using Tor and other > mechanisms). I don't see how we can engineer a low-latency (now even > 0-RTT) network security protocol that will do that in a performant > manner. When time comes and people have 10-40-100GE at home, maybe. > Infiniband would be nice. But that will still leave out use for 3rd > world countries (which still run on XP anyway). This is a technical list > and we should keep politics and FUD aside as best as possible. The architecture of the network protocol is the politics. There is no separation. RFC1984 and RFC 7258 cover this topic nicely. All the best, Jacob From nobody Thu Dec 3 08:15:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05CE1A8AFB for ; Thu, 3 Dec 2015 08:15:44 -0800 (PST) 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] 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 5YIS7rnaiz1p for ; Thu, 3 Dec 2015 08:15:42 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D481A88C8 for ; Thu, 3 Dec 2015 08:15:42 -0800 (PST) Received: by ioir85 with SMTP id r85so86109745ioi.1 for ; Thu, 03 Dec 2015 08:15:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=b7nJcXc0TaSClG4M3KBe2RehcOVR5QwzXpoFzCOB8Sc=; b=usXCrBz7CWDQizud/22yHv5jK9OmSCieoGOv2abbZkUQEo/s6u19tGJmu2VsFbadHo k0W37RWvHUzaZzwzg514766dEsh8+EVMylYyXbQ9aRTGM5V6tdilqTz1uLyV/lBG4IsB EoStSGysO5Sg9o9UXcRMjQpSW4fezYVpoI+Egzmgqt0sUIlvQsmy14TReIeYUQXcrWwd oRZZc4XS8gcdKH3mzbnPKF15iLigaxZqpLMd48Li/DAQGbz2+dyj2+3pKBDM/OVnoVcH 7j3yvg0mTNno1Ug2DiGjj7x7G6wvkyV4BJTICx6m16YQOUdxLDUOHut7O0sD+N0G8Ixg EPJw== 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=b7nJcXc0TaSClG4M3KBe2RehcOVR5QwzXpoFzCOB8Sc=; b=PPwLDfWR9VY/5ywj+DWnngdOWAT4W7qmKFzNwJNHL2KKkUwmiMfKFaSGueYeYsZIw9 HZv53erUehRo7ehwmfA7/SkhwayCBCSrUixKdc4mdu1hfctWRsJTq3XXPS0ckzTc3bJj RpMClEyg1W4uPXNGewtmNhjA++ICPxLx4SjytjxdEjcgKVwW5170H3yuC5M8FChqqWcb YiO7z7c2M8Swh7Od7dDg6VsevFQWpxxgpeCHPXkKnEiU11vKzU7lzmGCVjZlZ997KCZ7 Ou6j/gJp0FnfFlk4ad7TX/Mf7v5vWO0awJE9o7ky+NHfkeSFeXA5s4Az+DedC/4uPYbm o4EA== X-Gm-Message-State: ALoCoQlirLFdMHyDtxKuBd+Y+4UqwlF9VZNFYJEZ2cNFJJaVGgatdKMZrskPBS3lkItDF2V0KPDJ MIME-Version: 1.0 X-Received: by 10.107.137.19 with SMTP id l19mr8512449iod.138.1449159342080; Thu, 03 Dec 2015 08:15:42 -0800 (PST) Received: by 10.79.70.71 with HTTP; Thu, 3 Dec 2015 08:15:41 -0800 (PST) X-Originating-IP: [185.10.71.107] In-Reply-To: References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> <9BFA68AB-9677-4BE7-8F5E-D1A66EF95BA5@gmail.com> Date: Thu, 3 Dec 2015 16:15:41 +0000 Message-ID: From: Jacob Appelbaum To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 16:15:45 -0000 On 12/3/15, Watson Ladd wrote: > On Thu, Dec 3, 2015 at 6:36 AM, Jacob Appelbaum > wrote: >> On 12/2/15, Eric Rescorla wrote: >>> On Wed, Dec 2, 2015 at 7:34 AM, Jacob Appelbaum >>> wrote: >>> >>>> On 12/2/15, Eric Rescorla wrote: >>>> > On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford >>>> wrote: >>>> > >>>> >> On 02 Dec 2015, at 06:02, Martin Thomson >>>> >> wrote: >>>> >> > On 1 December 2015 at 08:22, Bryan A Ford >>>> >> > wrote: >>>> >> >> The 2-byte length field in each record's header no longer >>>> >> >> indicates >>>> >> >> the length of the *current* record but instead indicates the >>>> >> >> length >>>> of >>>> >> >> the *next* record. >>>> >> > >>>> >> > Ensuring that you know the length of the *next* record is >>>> >> > difficult >>>> >> > and could dramatically degrade latency, or adding extra bogus >>>> >> > padding >>>> >> > or extra bogus records. For instance, I can always send in burst= s >>>> >> > of >>>> >> > two packets, a one octet packet that promises the remainder of th= e >>>> >> > burst and one that promises a single octet packet. At that point= , >>>> >> > I >>>> >> > get to do what I've always done and you have gained little other >>>> >> > than >>>> >> > an increase in packet size of around 19 octets (best case). >>>> >> >>>> >> That type of inefficiency is extremely easy to avoid; please read >>>> >> the >>>> >> rest >>>> >> of my proposal where I discussed exactly that at length. Yes, a >>>> >> particularly stupid implementation could send everything in bursts >>>> >> of >>>> two >>>> >> packets, but it=E2=80=99s ridiculously easy for a slightly smarter >>>> implementation >>>> >> to avoid doing that. And what you=E2=80=99ve gained is complete en= cryption >>>> >> and >>>> >> integrity-checking of the whole TLS record before any part is >>>> >> interpreted, >>>> >> which seems like a nontrivial security improvement. >>>> > >>>> > >>>> > It's not really clear to me what the anti-traffic-analysis benefit o= f >>>> your >>>> > proposal >>>> > is over and above just padding everything to a fixed size. That's >>>> certainly >>>> > far >>>> > easier for the implementation to do, especially in typical stacks >>>> > where >>>> the >>>> > application just calls SSL_Write (or whatever) and so there's no >>>> > obvious >>>> > API point to provide the "next length", so as a practical matter the >>>> stack >>>> > will very often if not always be in "last block" mode. >>>> > >>>> >>>> I think that it eliminates all static distinguisher in the protocol >>>> for all data covered by the encryption. That is a fantastically >>>> wonderful benefit. >>> >>> >>> Wouldn't that benefit be equally achieved by simply padding all records >>> to a fixed length? You could do this with no protocol change and, as I >>> said, it's far easier for the implementation. >>> >> >> Padding is potentially useful but has two issues that come to mind >> which are both non-issues in most cases. The first is the economic >> cost for extra bytes and the second is the security of the padding >> scheme. >> >> Padding strategies are a complement super encryption but probably not >> a replacement. Padding protects against one set of attackers (bean >> counters) and super encryption provides confidentiality against >> another set of attackers (GPA/APA). > > But as several people have noted, encrypting record lengths doesn't > actually protect the lengths of the records > as well as you think it does. I think it protects the length data exactly as much as it does. :-) It doesn't solve the problem that for a given TCP flow, we'll have a byte counter, of course. That is also why I'm quite interested in DTLS with super encryption. Especially with users roaming across networks, I'm hopeful that we'll blind partial view attackers even more than ever. > Timing packets is not some exotic and > unavailable technology. I don't understand what > attacks padding and introduction of dummy packets doesn't defend > against that encryption of record lengths does. We should also ensure that we have padding and dummy packets, of course. Still I don't see that we'll turn TLS into ATM nor do I believe that we understand an optimal padding strategy. I think you are correct that an attacker with a clock and a bean counter is a valid problem. I also think that the more state we force an attacker to hold, the more expensive it becomes to perform correlated traffic analysis across global networks. Super encryption of records also means that accidents at one layer may not be as catastrophic at another layer. All the best, Jacob From nobody Thu Dec 3 08:25:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396DC1A8AF2 for ; Thu, 3 Dec 2015 08:25:39 -0800 (PST) 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] 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 jzwgfyTLhcQ4 for ; Thu, 3 Dec 2015 08:25:37 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6BB1A8AF1 for ; Thu, 3 Dec 2015 08:25:37 -0800 (PST) Received: by lffu14 with SMTP id u14so94088584lff.1 for ; Thu, 03 Dec 2015 08:25:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=LeiiX2bPbpJaiiCWOVmsFFAe/Kk45LJy1UnFCfMQfO8=; b=O3hxhmQJGKTsriJ//xCz5VnYkuoEVECUzODljm/dUOitj6ci3wKz7BIEksKrojwi4I R77lm/miyIo25qcj0uzLV7sD14t6GcvgBP3aWYxwSRNIHopng1XJKH/SNpBY4vvpDHiW bKg8uCwOYgtZQgRTlDns4YbgFa7+Up35KRI3w= 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; bh=LeiiX2bPbpJaiiCWOVmsFFAe/Kk45LJy1UnFCfMQfO8=; b=fLsFR0U8Hnoa1kIwPXF5lV5Znx5AYpRh519G/LFeOd3rLRS7vAs7hfsejrm9dkkCiJ /VixlGym03BY9/RazojXpors0M9kdzAJYWKJrvL3HPtZyBUAf9pPAqbvmxniesv19/z0 lVw/NNApwPMl/y48hiEh4QbelcfhJH1jYFTg8lX6upcisfwUE+mYzaXU3e7kvfDwduR0 2P8PzQeFxBadUPB194djTvaE7aCw+yn3T6T1VCkNEUGCALiMVtPebkVhO2Ji7ayn0v35 V+FUQAmj+KLUM7gA1hGhel8dZKzTnzE5Wv1uWUEG5522n0DqcMDHJM+/32fv/1BZtM0S TH/A== X-Gm-Message-State: ALoCoQncngJUOhQrU2d1DwfqN7RCkmUUcfWgHGQSl97CJ3HoCdTbge6mNl5bI+Imd/5kEw3e/VoA X-Received: by 10.25.15.213 with SMTP id 82mr5776257lfp.98.1449159935214; Thu, 03 Dec 2015 08:25:35 -0800 (PST) Received: from [192.168.1.103] ([41.232.113.177]) by smtp.gmail.com with ESMTPSA id o67sm1554256lfo.33.2015.12.03.08.25.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Dec 2015 08:25:33 -0800 (PST) Message-ID: <56606CF8.7070505@azet.org> Date: Thu, 03 Dec 2015 17:25:28 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Jacob Appelbaum References: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <1b5cf52ca90e45bd82f5247ca675dead@usma1ex-dag1mb1.msg.corp.akamai.com> <5660405E.3060008@azet.org> <56604CAF.5000305@azet.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig6367C5FF19894AA7A01CB036" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 16:25:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6367C5FF19894AA7A01CB036 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey, Jacob Appelbaum wrote: >> I don't think traffic analysis is in the treat model for TLS proper. >=20 > I'm confused by what you mean by traffic analysis. We encrypt content > in TLS because we know that we want confidentiality. We want that > because we know people do basic traffic analysis looking for sensitive > data in plaintext. I don't work in SIGINT nor for commercial networking vendors so I always have used jargon I picked up from Wikipedia: ``` Traffic analysis is the process of intercepting and examining messages in order to deduce information from patterns in communication. It can be performed even when the messages are encrypted and cannot be decrypted. In general, the greater the number of messages observed, or even intercepted and stored, the more can be inferred from the traffic. ``` -- https://en.wikipedia.org/wiki/Traffic_analysis My example, Pond, counters this with padding, randomized traffic patterns and - of course - Tor [0]. I'm just saying this is unpractical for a low-latency protocol such as TLS. I think we all agree there. >=20 > There are many kinds of traffic analysis adversaries. I think TLS > isn't trying to beat a global active adversary, for example, while > also providing anonymity. It seems that TLS is trying to beat a global > passive adversary from violating the confidentiality of the protocol. >=20 > A lack of confidentiality in many cases allows for attackers to do > better traffic analysis and selective denial of service attacks. > Failure to deal with very simple traffic analysis leads to much more > serious attack vectors being actively exploited in the wild. See my last message, I'm absolutely for encrypted-SNI. If it's feasible. If we end up with some compromise, maybe. But what we have now is nowhere near ideal. BTW, I played with SNI DoS a few months back (not too much though as it wasn't worth a paper), seems not to be as bad as it used to be because implementations nowadays have at least some counter-measures. > The architecture of the network protocol is the politics. There is no > separation. >=20 > RFC1984 and RFC 7258 cover this topic nicely. Bashing on random companies won't get us anywhere. I agree with you, but it's off-topic here. Most of the participants here do not represent their employer and even though some might have made a bad employment choice, it's up to them. They mostly speak for themselves and bring valuable implementer opinion to the table. Some break TLS on a massive scale and this is a problem (we have a vendor-nickname for a certain TLS extension after all). See also RFC7624, RFC7696. Aaron [0] - https://pond.imperialviolet.org/tech.html (Ctrl+S "traffic profile") --------------enig6367C5FF19894AA7A01CB036 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWYGz5AAoJEOTbZJL9ubXVr5kQALOzdRdFnrnniDIcBwQhBE4W 4lLn6ydAIm4VUv5/1q8Ah2AFMgnqSx2RAFC+VjzlFc2zI1Le8zG/k9yxiB8AW1If NUdxnktso2XH70NDZKTTUORddsv/OtSzXCDfccgJk/zMG03RUD5z2eX796EWdQKw BJ99HpN4rTvZkTDoqWMfID7+3DfJVDcBAx1zp5vR6JJ12mT3ga0S50tJ/nsTrRBH XQtTip0whaW67d7bHV3Xs/dv4AfE/+vFdzK00APDcZP1HPlbiqC7+87Xg5lA6Tbo sf4eAEvaY9iqauOyqlyfnZiWD/g3MA+6LMnzCipUWu8jPYPY7PU0LGCIRmNGQn1B fqN2OKTrFnVdVDNyblUkWc6UAFYmPdfORvVUk0G3rNdM2wSQfQ7bl/bFRQQucDG4 Hmgm6IKk2YFfIJPWJC53w9pJPMnfZ/KuCV4kuKzPERpZuZefXeYee5qPkRhbFooV eOK53Vwb18+9Mmn+oLCe5DSYBVWKNACA3/Fb5innVTUim1ZjDYVmg/xLuXGnRVV9 RjyT82Ctg8/BDk90ja8jc871McpqxX5aT2mXmAUsMUxhXNZpgZa4e1JwFDGuSRF+ Iws+c7FeOMnJskvh5/8EqYRT/OWj9b2ed5jtaw6NPOBf6Ux6hoXSDLs4Pxtssrx1 IFlfGZXg617WWlTwNYpP =mJtx -----END PGP SIGNATURE----- --------------enig6367C5FF19894AA7A01CB036-- From nobody Thu Dec 3 08:44:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C371A90F9 for ; Thu, 3 Dec 2015 08:44:14 -0800 (PST) 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] 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 fpc-thFCKETz for ; Thu, 3 Dec 2015 08:44:13 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501B01A90F8 for ; Thu, 3 Dec 2015 08:44:13 -0800 (PST) Received: by lbcdv4 with SMTP id dv4so5150524lbc.2 for ; Thu, 03 Dec 2015 08:44:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=1ZgKLCtEX7a9OrEzGwgJ5FoZFuKcIvzbwXI7nkkYGyQ=; b=hIzhL24z3EqZDR/uUNvrF2MwtZJhgiBhimaXmqyheweqpvfNmX4jlA9EKY3GFtxxuS p0WgOk/AdoQlBOJOrkH9Hu2vBPq5VHh/B2KGBNZ6CQm3Zw3eWpjbXLQLClyCCQS/1zN7 BF7x943KxbOURsJ43Gc2ppNXzUTZN0KDqObcY= 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; bh=1ZgKLCtEX7a9OrEzGwgJ5FoZFuKcIvzbwXI7nkkYGyQ=; b=MRQe8VvzC7klbExSM7yezsgbQ0f3/1nlRHm8o/lKwPUk+J5LnaLGiCFWfs9OFelyjW hMq4bjK92rdmD7STzWSKNDzhOjlqS3+rxD2ahtT/7wGzEZqLYtgJzWVO9P8Jmji9faK8 fSay6cz4nyNnj6RaKA/U1UFxIGoGrE4TUN529UrzczG0rnpKDOyNIrarLs6npcedbHtn p4qOUlkOMHSqFW0Mhih9ZN2e9oYUAnCwsVVkF4Zyb5QRwRF+YG3GAZy93GzZ5U/nbGol Dn/SRPj0AxWg9cfm6OuRLSx8KZVZkRV4BSPLh85ZkYfyNxKG4MpaQQ/C6ulk7MF6C+vV Lthw== X-Gm-Message-State: ALoCoQnA+tct8W+8tI45o5PBCT/R5kRvIyuwXzOErFFsHZM0OMNpix8l2W6tjMKTEyWzs0/Z7vd8 X-Received: by 10.112.158.66 with SMTP id ws2mr6277403lbb.126.1449161051423; Thu, 03 Dec 2015 08:44:11 -0800 (PST) Received: from [192.168.1.103] ([41.232.113.177]) by smtp.gmail.com with ESMTPSA id r2sm1560153lfe.28.2015.12.03.08.44.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Dec 2015 08:44:09 -0800 (PST) Message-ID: <56607154.60001@azet.org> Date: Thu, 03 Dec 2015 17:44:04 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Jacob Appelbaum References: <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <1b5cf52ca90e45bd82f5247ca675dead@usma1ex-dag1mb1.msg.corp.akamai.com> <5660405E.3060008@azet.org> <56604CAF.5000305@azet.org> <56606CF8.7070505@azet.org> In-Reply-To: <56606CF8.7070505@azet.org> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigFC5D092F3A4A65200E75A7F0" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 16:44:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFC5D092F3A4A65200E75A7F0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Errata: Aaron Zauner wrote: > BTW, I played with SNI DoS a few months back (not too much though as it= > wasn't worth a paper), seems not to be as bad as it used to be because > implementations nowadays have at least some counter-measures. Was supposed to say 'renegotiation DoS' I've looked at SNI as well in this context. Aaron --------------enigFC5D092F3A4A65200E75A7F0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWYHFVAAoJEOTbZJL9ubXVysAQAIeE8vJ+nisUK6B/revM82nS vfpPdkRocnE9Vh5CnEhQdNgoOb2UX9L18mP9mD4q12uZaSkUunH/QtyMJzdY5rXO ew0/xxmm6Dg41qQnQEe+fD5FKxnEvRo5KvwogOy5XhzCg1dN2tSB6tV6um9RH1fk 1HtfnrrvfqeSoO8AHJlvwMypksyfY66sBmnteLWKVL1K9bMQPAIf6q5gTbGJv/RT OO5wOvwIZt2vH3O89XPYcKUbUReGoIQhVItCilh38pagXAim1X5RF0w+Td0If7PB lE17k3vB8uzbs2jouW/CNKUvIcisChKDK2h3yc3up5i2TRgM/WnwhMyM4is4C+SQ B66Azd2BCfARp/vfotvBPPjrNvZO5S/fL02U5BVGu2U52bqWEUBqXu3SYHjr87xg IC0NROLCCRMJMu73pMArr8CzuFEdBBJg+tzB/wQtBUxM8K73VhyczASEGex5VQkJ CaOUx2nymGksbn7RxM9ImhhzAg6ZHtNERGPv/gYRvo0CGcxOrTRpPF+iQNaPb0/0 yVuTb7YbF7iiz9Ky2E1iW0YHYJb9bpNasC7NQNV+H2x2LsE8lx+ud93DwhFirNnF E9BwmDF/qbem6YtmWGvI3zGs0hq9cbSkHEgWIskst5wKv1a1ZVMKY3DsDL2uQKXi VG1wJjzoWK1JBQ+jK6cN =l82g -----END PGP SIGNATURE----- --------------enigFC5D092F3A4A65200E75A7F0-- From nobody Thu Dec 3 08:53:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951861A9149 for ; Thu, 3 Dec 2015 08:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.151 X-Spam-Level: X-Spam-Status: No, score=-5.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 BlnISA_B3rbk for ; Thu, 3 Dec 2015 08:53:47 -0800 (PST) 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 60EEE1A9233 for ; Thu, 3 Dec 2015 08:53:47 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3FAAD2B1DC; Thu, 3 Dec 2015 17:53:45 +0100 (CET) X-purgate-ID: 152705::1449161625-00001C04-6FD0736B/0/0 X-purgate-size: 1815 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id D9230408F6; Thu, 3 Dec 2015 17:53:44 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C639C1A3A0; Thu, 3 Dec 2015 17:53:44 +0100 (CET) In-Reply-To: To: Jacob Appelbaum Date: Thu, 3 Dec 2015 17:53:44 +0100 (CET) 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: <20151203165344.C639C1A3A0@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? 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, 03 Dec 2015 16:53:49 -0000 Jacob Appelbaum wrote: >> >>> To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less >>> secure >> >> That is a myth. > > Are you asserting that TLS 1.3 will be less secure or equally secure here? Even TLSv1.0 is sufficiently secure already, so that there are plenty of other attack surfaces *MUCH* easier to attack. http://www.schneier.com/books/practical_cryptography/preface.html Arguing about whether a key should be 112 bits or 128 bits long is rather like pounding a huge stake into the ground and hoping the attacker runs right into it. You can argue whether the stake should be a mile or a mile-and-a-half high, but the attacker is simply going to walk around the stake. If you design anything around TLS where the "secrecy" of the servername is important, then you are acting extremely irresponsible. There are so many ways and places where the servername WILL be leaked, (URLs, bookmarks, HTTP-Header-Fields, HTTP-Referer headers, etc.) that bottom line, encrypting SNI amounts to crazy and pointless idea. Using sha1(servername) instead of servername is (a) not confidential and (b) backwards-incompatible with the existing protocol&usage and the installed base. No matter how many hoops you jump, encrypting SNI will never become anything close to a TOR hidden service. And for the vast majority of servers, there is going to be such a small number of virtual services, that distinguishing them will always be trivial by their traffic patterns. There is nothing that TLS could do about app-determined traffic patterns of unrelated TLS sessions. You could use innocent servernames or multi-SAN server certs plus *NO* SNI. and both would provide higher security and be much easier to implement than encrypting SNI. -Martin From nobody Thu Dec 3 09:40:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F641A00A1 for ; Thu, 3 Dec 2015 09:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 hlAXLhiJMf4x for ; Thu, 3 Dec 2015 09:40:09 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34241A01D5 for ; Thu, 3 Dec 2015 09:40:04 -0800 (PST) Received: by qgec40 with SMTP id c40so66520697qge.2 for ; Thu, 03 Dec 2015 09:40:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=V6GhEN+72VWFt+4kyGXNFJVDR+gLp2I5x0ZcFzeL9Tg=; b=iDT5Qg3nbPykiKoh/dCCMAqt9Yiyw8vxfbELdzzzEH7BW6qwD80DR/MGKa5Y+ClawF t0Kx4CGwaA6ToFQAOA9nYBBmBVEdyC9//+GIb4yqAqgh1y1cc8io3+uLnSX7ixVv3xD7 6bRST+gZPPshxpOb5B0MDTcWf+4i6vEqcJ2ZA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=V6GhEN+72VWFt+4kyGXNFJVDR+gLp2I5x0ZcFzeL9Tg=; b=krWnj9Q8cn3nCAfdhxNE1Hn6/O+LhxZ1cz6+e0tvrCWVPsjXor+yaxdVI8QhRUi8Xj uDDTe7lhEnLRrWvrp22UcwVcusFI13MmTMOADyZrby94EFD0FkuONigikB001E+IPzSL cShevECcMjTXGC48zNw1HOk+ZODXoQbMWOoN2L2zHv6auNQRSlQTTkOKaWRQrv0un22c iiyYTGQBWdd6Gd6dHRxcuXulmXx9OBaukTz414OfBclo38xkXB1E7aTu7OZOrFszPNlw VNwxOV9Q9KShsHybLN6EJjcEso0jZGEUFW+Theg5yvDwiMix2xPXRs2KtOS092Fd2eJq wJzQ== X-Gm-Message-State: ALoCoQnlNMcsHyvQ0a3DyUvm+wgn1qU0JUUfU0fWCIKbvfKRJLL+bIuHr0Poyj2celZSxMk6bp2X X-Received: by 10.140.34.204 with SMTP id l70mr12545094qgl.7.1449164403910; Thu, 03 Dec 2015 09:40:03 -0800 (PST) Received: from [172.16.0.112] (pool-173-73-126-234.washdc.east.verizon.net. [173.73.126.234]) by smtp.gmail.com with ESMTPSA id g3sm3369597qhg.12.2015.12.03.09.40.03 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Dec 2015 09:40:03 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <12A6FBAD-C9F1-434C-9910-F7E974F59B0B@sn3rd.com> Date: Thu, 3 Dec 2015 12:40:02 -0500 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: [TLS] IETF 94 meeting minutes posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 17:40:10 -0000 All, I=E2=80=99ve been a bit delinquent with posting the minutes but they are = now up: https://www.ietf.org/proceedings/94/minutes/minutes-94-tls They=E2=80=99re pretty much what Jim entered into the etherpad with only = minor corrections (typos and filling in some names). If you have = comments please send them by 20161215. spt= From nobody Thu Dec 3 10:41:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55B01B352F for ; Thu, 3 Dec 2015 10:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_BACK=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 Fg4cEMY2LC_K for ; Thu, 3 Dec 2015 10:41:08 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C3B1ACDA4 for ; Thu, 3 Dec 2015 10:41:08 -0800 (PST) Received: by lbblt2 with SMTP id lt2so7195238lbb.3 for ; Thu, 03 Dec 2015 10:41:06 -0800 (PST) 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:content-transfer-encoding; bh=UHYjNVAJGNcJ9rFZGHHyb1AbtNqASXhUHZZNqTOa4IA=; b=wYGQI0wnesTEeW56y7gk58QxcW32ZzdgSMHDXzqzRMoHTT1PMc88USVDeRHmpkH6Qd Jk//cARZrYKjx+nRimGiRPv/JMTM1nEak6x24tM8YbXtWefHESZeR2711aCM/aXeAStQ GpSI2ooU4qOoxaipjrLz/M9D9mJRO7gEJcLO16gWBMo+xfdYfBKz7Mgk5kfpMe3ujK3y PUWUYuJOtJsU+sC30HI34sdHDj2F9cNfa4eH4eOfUB5/aR1N6kwOZTwqrnqKDFn7dFCm Cs51haALtAKR5kEgXIXfrNh8GhPaPkSMgCOQl74esWQwFtPKSCPNxef2pGQpk+at1fmt Pa2w== X-Received: by 10.112.130.231 with SMTP id oh7mr6398882lbb.88.1449168066443; Thu, 03 Dec 2015 10:41:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.207.135 with HTTP; Thu, 3 Dec 2015 10:40:47 -0800 (PST) In-Reply-To: <1449051281.4345.31.camel@redhat.com> References: <20151201210257.64f1a7a5@pc1> <1449051281.4345.31.camel@redhat.com> From: Fabrice Gautier Date: Thu, 3 Dec 2015 10:40:47 -0800 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] Fresh results X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 18:41:09 -0000 On Wed, Dec 2, 2015 at 2:14 AM, Nikos Mavrogiannopoulos w= rote: > On Tue, 2015-12-01 at 21:02 +0100, Hanno B=C3=B6ck wrote: >> On Tue, 1 Dec 2015 14:28:49 -0500 >> Watson Ladd wrote: >> >> > https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls >> > 13QuicAttacks.pdf >> > >> > This one looks very nasty to fix. Short of disallowing the use of >> > RSA >> > certificates for TLS 1.2 with the RSA handshake and in TLS 1.3, I >> > don't see a good fix. I haven't read this paper in detail yet. >> > >> > Cross-protocol attacks are the gift that keeps giving. >> >> Correct me if I'm wrong, but as I understand the result (and I had >> one >> of the authors explaining it to me a few days ago) the problem >> appears >> only if you have a TLS 1.2 implementation with an RSA keyexchange >> that >> is vulnerable to a bleichenbacher attack. If it is not then you're >> fine. > > The interesting result of the paper is: > "Even though this limits the > practical impact of this attack, it demonstrates that simply > removing a legacy algorithm from a standard is not necessarily > sufficient to protect against its weaknesses." > > Even though the attack does not work for current implementations it > underlines that if you reuse keys from TLS 1.2 to TLS 1.3 you don't get > any advantage from the better algorithms in TLS 1.3. You are as safe, > as if you'd be using TLS 1.2. > > That can be claimed to be trivial result given that it is underlined on > almost every paper that describes a cross-protocol attack, but it is > not still grasped by the engineering community. There have been > described quite some cross protocol attacks (Kerberos 4 -> Kerberos 5 > by Yu et al., TLS between ciphersuites starting by Wagner and > Schneier), but still we reuse keys between protocols. Can we solve that problem generically by having TLS implementations use different certs for different TLS version, and have an indicator in the certs to indicate which version(s) they are for ? -- Fabrice > > regards, > Nikos > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Dec 3 12:48:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306FB1AC3E3 for ; Thu, 3 Dec 2015 12:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_BACK=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 i1HjwJJL4N0b for ; Thu, 3 Dec 2015 12:47:57 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2191AC3D8 for ; Thu, 3 Dec 2015 12:47:57 -0800 (PST) Received: by wmww144 with SMTP id w144so38824797wmw.0 for ; Thu, 03 Dec 2015 12:47:56 -0800 (PST) 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=FNbkbHpBmtUllxpNtKEUvaKVdUAH7qATyzUfhXpoYVk=; b=o+N8YTupm97Rt2nCKo86ycg+0OQZN6fkNWdqrIu7H8qDaOA0nlAU7K+PtOr3U0Gxy/ IT9mx7UVXmbIq6bE3nCMOjATPtlF+xYKxoCx6Zv3c6+wyvXlLzgFq4AhXcvQ0X5pciC6 HpbK3dC7NVWz3ytooBxaVbZln/LwGuXLUvbdtB/tYZncyUpYc64uNoPXhY1vvGCyNEA2 kNaDBcTzcdb2zo37q74EArxcJcYjDupAAEvAaBDaE8b6rRXK37QAPhAIU/s52m4xaL0t mSI5uwsw49iu74bQ0D06NgesXysPh9mlcLz9psyBXPb3/Tn6xke+GPP/CRjlofCnnG6m +v2w== X-Received: by 10.194.200.5 with SMTP id jo5mr13208676wjc.79.1449175675996; Thu, 03 Dec 2015 12:47:55 -0800 (PST) Received: from [192.168.1.10] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id q9sm9189489wjo.9.2015.12.03.12.47.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Dec 2015 12:47:55 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: Date: Thu, 3 Dec 2015 22:47:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24527269-956F-4DFD-8801-1A5331DF0C20@gmail.com> References: <20151201210257.64f1a7a5@pc1> <1449051281.4345.31.camel@redhat.com> To: Fabrice Gautier X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "" Subject: Re: [TLS] Fresh results X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 20:47:59 -0000 > On 3 Dec 2015, at 8:40 PM, Fabrice Gautier = wrote: >=20 > On Wed, Dec 2, 2015 at 2:14 AM, Nikos Mavrogiannopoulos = wrote: >> On Tue, 2015-12-01 at 21:02 +0100, Hanno B=C3=B6ck wrote: >>> On Tue, 1 Dec 2015 14:28:49 -0500 >>> Watson Ladd wrote: >>>=20 >>>> https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls >>>> 13QuicAttacks.pdf >>>>=20 >>>> This one looks very nasty to fix. Short of disallowing the use of >>>> RSA >>>> certificates for TLS 1.2 with the RSA handshake and in TLS 1.3, I >>>> don't see a good fix. I haven't read this paper in detail yet. >>>>=20 >>>> Cross-protocol attacks are the gift that keeps giving. >>>=20 >>> Correct me if I'm wrong, but as I understand the result (and I had >>> one >>> of the authors explaining it to me a few days ago) the problem >>> appears >>> only if you have a TLS 1.2 implementation with an RSA keyexchange >>> that >>> is vulnerable to a bleichenbacher attack. If it is not then you're >>> fine. >>=20 >> The interesting result of the paper is: >> "Even though this limits the >> practical impact of this attack, it demonstrates that simply >> removing a legacy algorithm from a standard is not necessarily >> sufficient to protect against its weaknesses." >>=20 >> Even though the attack does not work for current implementations it >> underlines that if you reuse keys from TLS 1.2 to TLS 1.3 you don't = get >> any advantage from the better algorithms in TLS 1.3. You are as safe, >> as if you'd be using TLS 1.2. >>=20 >> That can be claimed to be trivial result given that it is underlined = on >> almost every paper that describes a cross-protocol attack, but it is >> not still grasped by the engineering community. There have been >> described quite some cross protocol attacks (Kerberos 4 -> Kerberos 5 >> by Yu et al., TLS between ciphersuites starting by Wagner and >> Schneier), but still we reuse keys between protocols. >=20 > Can we solve that problem generically by having TLS implementations > use different certs for different TLS version, and have an indicator > in the certs to indicate which version(s) they are for ? That=E2=80=99s a heavy-handed approach that requires servers to have = multiple certificates and new selection logic. Wouldn=E2=80=99t it be better to mandate that if your TLS implementation = supports both TLS 1.2 and TLS 1.3 it should take actions necessary to = mitigate the bleichenbacher attack? In fact, if you don=E2=80=99t care much about very old browsers, isn=E2=80= =99t it possible today to mandate that the TLS implementation not use = RSA keying? That way the oracle is gone. Seems better than requiring web server administrators to acquire two = certificates. Yoav From nobody Thu Dec 3 13:16:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736171ACCE1 for ; Thu, 3 Dec 2015 13:16:53 -0800 (PST) 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, 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 9HvXyFfJmRdi for ; Thu, 3 Dec 2015 13:16:52 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B1F1A92EF for ; Thu, 3 Dec 2015 13:16:51 -0800 (PST) Received: by lbblt2 with SMTP id lt2so9535504lbb.3 for ; Thu, 03 Dec 2015 13:16:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=jGzxBZr+pmXdQG/gPkqteOhI8KLgh/vEfvHtsUubD4c=; b=t3/7XIoAhYjzhFf9/fgmcRLnZ2eRCXuT6bwKgGF+iIuB/2MFylSPjj8IofyGuyij8z gwO2B7U+KACdDKWd0pOKEqmm0CGJBnB0echO1RDSaICsQ2+tXNAZSB1qZhxYoFoOL9Lh nep8KlWUTIC5TPyUGqHt4gPDUJ6ynr0ndk/0bkvgYGNgeePytEgJNF+4stkcAxqns2AM s8ZPrLSEVEBBcwP5HwstPtvD+bBjTsK7xN1g3PpYg4cmO0XyA4y9x5ffVcTJWIfq9kg2 tISdrIEaSm3h4+tC5ij/piaHv2iXYy4J3D3x6WcoZfy8WRtF1kWfWWDmj67fv1CNGhOO Eo0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=jGzxBZr+pmXdQG/gPkqteOhI8KLgh/vEfvHtsUubD4c=; b=gUro1C79cgxU3RsNyZWYxsfHwKGnthz1+FXiewbtph51YO16Cx7NTbcdBIGZ0WSiBX BkupAfN0DlL8ggfbOCNBR+sE9spFa3cEwXv7MfkGOqR0ICCc3ECzrBvEoByymW+T2djp +PjVZ6eEZbhZb7vGYivnWwA4lxhpt4JwCTPYFq4vZ8QZo0GAq7nnefwYpSwe+hZsbJE5 k9u46xLX3vYRO7DzYlTmraQfiGo+gRpHlnxzBr5apgEDyGqSg7is47VXlyKZQgVK/pnf j4gqDelsretFNlp2wiJz7e6OmMVLRV0/WGK8qo8NGGVztvWEm6bcFUrfOqM3Uv6ZAyBd rlOg== X-Gm-Message-State: ALoCoQm29XPUcg33SToa8rv2ynASwcxs/8xn1VgUDXixY8/QAoP47RCvHeCpYnL/qnrjA9niXakk MIME-Version: 1.0 X-Received: by 10.112.171.74 with SMTP id as10mr6343080lbc.137.1449177409697; Thu, 03 Dec 2015 13:16:49 -0800 (PST) Received: by 10.112.24.131 with HTTP; Thu, 3 Dec 2015 13:16:49 -0800 (PST) Date: Thu, 3 Dec 2015 13:16:49 -0800 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c37fbab8d0a9052604e863 Archived-At: Subject: [TLS] WGLC for ChaCha20-poly1305 ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 21:16:53 -0000 --001a11c37fbab8d0a9052604e863 Content-Type: text/plain; charset=UTF-8 draft-ietf-tls-chacha20- poly1305-03 has been submitted incorporating feedback from working group discussions. In particular the construction now matches what is used in TLS 1.3. Please review the draft and send any comments by December 17, 2015. Thanks, J&S --001a11c37fbab8d0a9052604e863 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
draft-ietf-tls-chacha20-poly1305-03 has been submitted= incorporating feedback from working group discussions. In particular the c= onstruction now matches what is used in TLS 1.3. =C2=A0 Please review the d= raft and send any comments by December 17, 2015. =C2=A0

Thanks,

J&S
--001a11c37fbab8d0a9052604e863-- From nobody Thu Dec 3 14:31:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18891ACF54 for ; Thu, 3 Dec 2015 14:31:15 -0800 (PST) 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 tLJaT0Ch493U for ; Thu, 3 Dec 2015 14:31:14 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5421ACF57 for ; Thu, 3 Dec 2015 14:31:11 -0800 (PST) Received: by qgeb1 with SMTP id b1so74449905qge.1 for ; Thu, 03 Dec 2015 14:31:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=ntYcZmuYLJ9gNKc4uZj6ffJBFgyCjTaRgSfTZTf2i3M=; b=hZjYomfE1Xar0hsoKxpSSGd59gXaUw328FmmGcOsWlM5GhQabacRabZMjQs5JOlrXt QbiR+XLuDxo2EOTD8cOswYLWuU9rVOa43M5X240R3BPJjTSEfWMQtoziy67Tann6P9oa T+y7LO2vSon3FCoaz1QV6Gq/8YueLKobt2Py0GQbHyseJiY3cRnYodd6YeBBBBkyYuLb bPYKp74xNWuzvlMghApOTJJUwB6pSNdt7z3Aa3I+xiFlbJIJ07r7SGLoLTBH+UVBRrdQ CWwasfUkqca+zOpLNHmKzXPCcO5Ep85XG4YYyIY3s7Ed3FCgzlxYsH87+iS3QMrL6zXC wh+A== X-Received: by 10.140.96.76 with SMTP id j70mr14177327qge.100.1449181870842; Thu, 03 Dec 2015 14:31:10 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id p19sm4217132qgp.9.2015.12.03.14.31.09 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 03 Dec 2015 14:31:10 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Thu, 3 Dec 2015 17:31:07 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <24527269-956F-4DFD-8801-1A5331DF0C20@gmail.com> In-Reply-To: <24527269-956F-4DFD-8801-1A5331DF0C20@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201512031731.08321.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Fresh results X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 22:31:15 -0000 On Thursday, December 03, 2015 03:47:52 pm Yoav Nir wrote: > Wouldn=E2=80=99t it be better to mandate that if your TLS implementation = supports both TLS 1.2 and TLS 1.3 it should take actions necessary to mitig= ate the bleichenbacher attack? >=20 > In fact, if you don=E2=80=99t care much about very old browsers, isn=E2= =80=99t it possible today to mandate that the TLS implementation not use RS= A keying? That way the oracle is gone. >=20 > Seems better than requiring web server administrators to acquire two cert= ificates. A draft of the simple solution: https://github.com/davegarrett/tls13-spec/commit/edeed6e90c177df6670935fcee= a69e14b3951e53 Dave From nobody Thu Dec 3 15:45:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3911AC3C5 for ; Thu, 3 Dec 2015 15:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 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, MANGLED_BACK=2.3, 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 PXfkYDp3Wt1r for ; Thu, 3 Dec 2015 15:45:15 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F2E11AC3AB for ; Thu, 3 Dec 2015 15:45:15 -0800 (PST) Received: by ykdv3 with SMTP id v3so105729074ykd.0 for ; Thu, 03 Dec 2015 15:45:14 -0800 (PST) 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=lLMAHE3+b8gQeil4pF1RDWYaHSUaCuhMvKrZ2VRWbIc=; b=j+WjwvjkmJdaKILnFVHKDSl1Q/Zfp7HniF5EqJ9tWwtlESOQe3JCLDsvgtEQw+ziKZ WqBhhawGC3ezlDr9UpskzcS2a3b9pHnfXgzca5iFdzk50ob9mZbcJ9c4I0ylU4ma5Phr 0zTECeAEA5x4KpS+IfvRlHeZZcgkbZPhLrM7pk14d5PrtDvA6mc8crmfiOme6MtFt59W 5g15pZytUERr14ipIWhvQ4U+oZ+vWJtjPoMWbtdGc4nvgrZI0AcraaiB2xbQ/lxmAXTg O8+ztnCHOukxp93ip8k36bVgsg/AK0TSwKcDZe6hW9JKbfSlBySnmiKCO9Zjwn62eUM7 VvTA== MIME-Version: 1.0 X-Received: by 10.13.193.6 with SMTP id c6mr9135989ywd.326.1449186314417; Thu, 03 Dec 2015 15:45:14 -0800 (PST) Received: by 10.129.148.131 with HTTP; Thu, 3 Dec 2015 15:45:14 -0800 (PST) In-Reply-To: <20151201210257.64f1a7a5@pc1> References: <20151201210257.64f1a7a5@pc1> Date: Thu, 3 Dec 2015 18:45:14 -0500 Message-ID: From: Watson Ladd To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fresh results X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 23:45:16 -0000 On Tue, Dec 1, 2015 at 3:02 PM, Hanno B=C3=B6ck wrote: > On Tue, 1 Dec 2015 14:28:49 -0500 > Watson Ladd wrote: > >> https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13Qui= cAttacks.pdf >> >> This one looks very nasty to fix. Short of disallowing the use of RSA >> certificates for TLS 1.2 with the RSA handshake and in TLS 1.3, I >> don't see a good fix. I haven't read this paper in detail yet. >> >> Cross-protocol attacks are the gift that keeps giving. > > Correct me if I'm wrong, but as I understand the result (and I had one > of the authors explaining it to me a few days ago) the problem appears > only if you have a TLS 1.2 implementation with an RSA keyexchange that > is vulnerable to a bleichenbacher attack. If it is not then you're fine. > > So as long as you make sure you implement all the proper > countermeasures against that you should be fine. (Granted: This is > tricky, as has been shown by previous results, even the OpenSSL > implementation was lacking proper countermeasures not that long ago, > but it's not impossible) Can you describe the complete set of required countermeasures, and prove they work comprehensively? What if the code is running on shared hosting, where much better timing attacks are possible? What's shocking is that this has been going on for well over a decade: the right solution is to use robust key exchanges, and yet despite knowing that this is possible, we've decided to throw patch onto patch on top of a fundamentally broken idea. There is no fix for PKCS 1.5 encryption, just dirty hacks rooted in accidents of TLS. > > Deprecating the RSA keyexchange just became a bit harder with Google's > intent to deprecate DHE in Chrome and use RSA as the fallback if the > host doesn't do ECDHE. > > -- > Hanno B=C3=B6ck > http://hboeck.de/ > > mail/jabber: hanno@hboeck.de > GPG: BBB51E42 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu Dec 3 15:46:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993401AC3E1 for ; Thu, 3 Dec 2015 15:46:43 -0800 (PST) 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] 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 b0GttmG7Tj30 for ; Thu, 3 Dec 2015 15:46:42 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB1C1ACC88 for ; Thu, 3 Dec 2015 15:46:41 -0800 (PST) Received: by igcto18 with SMTP id to18so24312411igc.0 for ; Thu, 03 Dec 2015 15:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o69xB5W2BbxtGMkpZRfFmQWkudJ5xwnjdJjd70gW95o=; b=RO9cZoo0qqX/q4dPpErhnpm1XMEhnYytES1JgM6Aw8mwcFpFon/0fCkjmdtOTif3af TdeKyw6pn5mGgR5LA09ZWPERbNHsCqXL/PlrWpXUF7NBGeL6hblcqx2xFS706pRwgNLC qc5H5qhSfw5WsRCu56soqtgyjRf+feRZqFEoc7BzP5sNn7xZpFsMg7xxjIA+aNrIYBq0 ceu9zOzWcqvkoM5SfmlayRFVcTJeLEPtk99vsfREX5zB5x2W0fyZWhgSjvkvtRrYDqLr 3epEgV9SEkdRpfhdc9+b8P9Jjk0Q+lWeq0fvF02EdUkwFCZS5GDlHjJN5aKN6akzrunJ SZlQ== 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=o69xB5W2BbxtGMkpZRfFmQWkudJ5xwnjdJjd70gW95o=; b=OnPlW3OYhOtEipCh2OsVxP5CN9ZqbbzE1LTxbKTpYpnHWh5z1JYIffEESL8YAtz9oC IkWb9Z+KASLi/0ZdJiUt48irtduiB16ovkEzfcPMQ0HHyB7vJ7nZWL340r6Rb0glGchp iMuKQfI+Bseb+VW0vupZL0S4w6sUajbWUgG37zzBfXPE/DO21JAb6w8cZ5njZdPUPaaR ex2pTkvsIiVt3A2KB596EcGv+GgApOE5N44K40fR4MVymMYKlD7f8DeKfUmdrNJeG7mN YHFUxJgVKLOzcFhnE7wLiBR9a7i/XJDaVF59PWvvf6qTHebOLliOhHmqlfHdL6dwnWAq mmww== X-Gm-Message-State: ALoCoQkgT2mlUsMU6SKl378bmOy5Ec7L0GBh1bCC0k+KjOhzO3jmcgEtz4u4ipplV7kVOM6iMB0rJE+pKkJ7jEEonKy3G/IyaQ== MIME-Version: 1.0 X-Received: by 10.50.49.109 with SMTP id t13mr1301582ign.89.1449186401284; Thu, 03 Dec 2015 15:46:41 -0800 (PST) Received: by 10.79.70.71 with HTTP; Thu, 3 Dec 2015 15:46:40 -0800 (PST) X-Originating-IP: [185.38.14.215] In-Reply-To: <20151203165344.C639C1A3A0@ld9781.wdf.sap.corp> References: <20151203165344.C639C1A3A0@ld9781.wdf.sap.corp> Date: Thu, 3 Dec 2015 23:46:40 +0000 Message-ID: From: Jacob Appelbaum To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 23:46:43 -0000 On 12/3/15, Martin Rex wrote: > Jacob Appelbaum wrote: >>> >>>> To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less >>>> secure >>> >>> That is a myth. >> >> Are you asserting that TLS 1.3 will be less secure or equally secure >> here? > > Even TLSv1.0 is sufficiently secure already, so that there > are plenty of other attack surfaces *MUCH* easier to attack. > > http://www.schneier.com/books/practical_cryptography/preface.html > > Arguing about whether a key should be 112 bits or 128 bits long is > rather like pounding a huge stake into the ground and hoping the > attacker runs right into it. You can argue whether the stake should > be a mile or a mile-and-a-half high, but the attacker is simply going > to walk around the stake. I look forward to using that poor saps TLS 1.0 services - where TLS isn't the weakest link! > If you design anything around TLS where the "secrecy" of the servername > is important, then you are acting extremely irresponsible. There are so > many ways and places where the servername WILL be leaked, (URLs, bookmarks, > HTTP-Header-Fields, HTTP-Referer headers, etc.) that bottom line, > encrypting > SNI amounts to crazy and pointless idea. > Huh - Could you please enumerate all of the places that TLS leaks a hostname requested by a client? Each one of them is a problem and we should correct it. TCP/IP and DNS are out of scope, though obviously related. > Using sha1(servername) instead of servername is (a) not confidential > and (b) backwards-incompatible with the existing protocol&usage and > the installed base. That was not a serious suggestion. If you think that I seriously suggested hashing the server name, I'm sorry. Please re-read my email and understand that I was suggesting that we can change the value of a field easily to make the attack more expensive. To make it worth doing, we want a better scheme than a straight hash of a name, of course. > No matter how many hoops you jump, encrypting > SNI will never become anything close to a TOR hidden service. > And for the vast majority of servers, there is going to be such > a small number of virtual services, that distinguishing them will > always be trivial by their traffic patterns. There is nothing that > TLS could do about app-determined traffic patterns of unrelated > TLS sessions. We probably agree here - there is a case where you want to compose with Tor. However there is a different issue which is that by leaving the client requested name in the clear, an attacker, even against a Tor exit node, can denial of service a specific client with nothing more than a word list. This is no different from HTTP without TLS for tearing a connection down; it becomes different with TLS 1.2 and DTLS (and probably with something like Bryan's super encryption). Sadly, DTLS doesn't compose with Tor and so, we want a similarly hard to distinguish TCP protocol that does compose with Tor. None the less - eventually a long term attacker may be able to learn things about public websites (eg: which wikipedia page you visited) - for non public websites, I don't believe that you can make the same claim. Additionally, the bar for an attack has just been seriously raised from ngrep to a pretty sophisticated attacker with long term funding. > You could use innocent servernames or multi-SAN server certs plus *NO* SNI. > and both would provide higher security and be much easier to implement > than encrypting SNI. I look forward to your proposal that removes the need for encrypting SNI. I think it will be interesting to compare your construction with the soon to be shown encrypted SNI proposal. All the best, Jacob From nobody Thu Dec 3 15:52:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870B31ACE19 for ; Thu, 3 Dec 2015 15:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.898 X-Spam-Level: * X-Spam-Status: No, score=1.898 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 5pkywoz3i7E1 for ; Thu, 3 Dec 2015 15:51:58 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1791ACD34 for ; Thu, 3 Dec 2015 15:51:58 -0800 (PST) Received: from pc1 (0x3ec7a652.inet.dsl.telianet.dk [::ffff:62.199.166.82]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Fri, 04 Dec 2015 00:51:55 +0100 id 00000000000000AA.000000005660D59B.0000087B Date: Fri, 4 Dec 2015 00:52:08 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: Watson Ladd Message-ID: <20151204005208.5b9aad75@pc1> In-Reply-To: References: <20151201210257.64f1a7a5@pc1> X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-2171-1449186715-0001-2" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fresh results X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Dec 2015 23:52:00 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-2171-1449186715-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 3 Dec 2015 18:45:14 -0500 Watson Ladd wrote: > On Tue, Dec 1, 2015 at 3:02 PM, Hanno B=C3=B6ck wrote: > > So as long as you make sure you implement all the proper > > countermeasures against that you should be fine. (Granted: This is > > tricky, as has been shown by previous results, even the OpenSSL > > implementation was lacking proper countermeasures not that long ago, > > but it's not impossible) =20 >=20 > Can you describe the complete set of required countermeasures, and > prove they work comprehensively? What if the code is running on shared > hosting, where much better timing attacks are possible? What's > shocking is that this has been going on for well over a decade: the > right solution is to use robust key exchanges, and yet despite knowing > that this is possible, we've decided to throw patch onto patch on top > of a fundamentally broken idea. There is no fix for PKCS 1.5 > encryption, just dirty hacks rooted in accidents of TLS. No disagreement here. The thing is, we have a bunch of difficult options to choose from: * Fully deprecate RSA key exchange. The compatibility costs of this one are high. They are even higher considering the fact that chrome wants to deprecate dhe and use rsa as their fallback for hosts not doing ecdhe. ecdhe implementations weren't widespred until quite recently. A lot of patent foo has e.g. stopped some linux distros from shipping it. * Separate keys for TLS 1.3 and TLS <=3D 1.2. Complicated. Certificates are already too complicated for many people. Do we really want to add more complexity by having different certs for different TLS versions? * Make sure proper countermeasures are implemented. Also difficult. I just learned nss is not bleichenbacher-timing-safe. Sounds like three bad options to me. --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-2171-1449186715-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWYNWoAAoJEKWIAHK7tR5Cy0sQAJWUESyCL6VZd2LAGrOKKBum DWdByFKwcUhy77MJp5wD5H4o3I6OZdZpuLwogf31EhanLKDvmGt2pL2ZlTC1RcKz 8CJhw5TFHfW6wegi6Oy0eYhAkyAdDhtwendPYsLlmBMK2lssHp2dlhgYdco8M76b tUcvUKNBa3aQClWKRZv798s8IucTvHLJZxGwj2c6VhLSwTBfTEy+IsSbsIR4v9a/ f/hYcA72dN0v32b8DWVTKXvjT991p3sUrd0oyI33cRvee6MWM5h2AnXHDNxkxjCs ODK4Gq74wWbQsgdDTL/SQNznuTr/RwTQugyygEEr/PjO2OeKfd7SguXxXd7r7O7j W5DK0HTs8yzE/8068drYAqKvmB38pJVEasFkm0LNYFuuIYZrKX0kopI689xDPFRI G3ZYSLT8BSQbX1FHJbshGO7Us/FGIpXq49LnH997E+TakuD9i/xFzZ0bKeEK4eTc xzH1T/tjeEd7Nq7W0TbRnaVLLD2dJ6lEZwYZibm36h5aTtpYUvIAtpSwVtrh2WNl QpskgbgQps4OMHMzo7DcmKTuMyeHwsMlJrwtXNOEu5bN9P3rlq32FJYBBgdit2Bt 5rlLj6ZY1ftSmdkEd1d4f0UYY86Am/3PEW9hXxML7GuzrCZ/7nvwCGrB8pfye+ok Zzlcle4l0MamZWy6uTfZ =/Tv5 -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-2171-1449186715-0001-2-- From nobody Thu Dec 3 17:07:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFDC1A1AFB for ; Thu, 3 Dec 2015 17:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_BACK=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 t29ST8sugkjx for ; Thu, 3 Dec 2015 17:06:58 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04511A1B0B for ; Thu, 3 Dec 2015 17:06:58 -0800 (PST) Received: by pfu207 with SMTP id 207so17144164pfu.2 for ; Thu, 03 Dec 2015 17:06:58 -0800 (PST) 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=Mhqz1KYJqoiCdk4qeVWRRm5dNV+8k2DLBo35xh4D3pI=; b=Jhk0MYgrjcaGGU2E/IFdW6hXeADkByZHZCL+cFnfVR47XIaf/1skTLEmi4Odkincao to1/0f/t+N1TgKyJlH0MmaaWL4BmoFsjGa7nU3pjzogoSuzWS3WJ1YZrFyNgf08iSfY6 oCGOjTxEqNIYZPnnYElFyugjUqWhrnDUWgeAVKj/uqeqNUv1UPiLK8SqqVndr2wR8NKK RKt80St6lCZ9Q/rqpgG5D+soK6nYDnKOZqT0F60BJG+FX4Nklf+ej5+phLhXFtaoq4Q+ q7tNsNV27+9XZXs9gAGldeKHCPWv01QF4esPxtGDVQAHbfxgSphX/zfTJ6XppyuXNOTy LL5w== X-Received: by 10.98.7.129 with SMTP id 1mr17630234pfh.70.1449191218288; Thu, 03 Dec 2015 17:06:58 -0800 (PST) Received: from ?IPv6:2600:1010:b04c:a29b:142d:568c:76e4:bd76? ([2600:1010:b04c:a29b:142d:568c:76e4:bd76]) by smtp.gmail.com with ESMTPSA id dz6sm13117052pab.19.2015.12.03.17.06.56 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Dec 2015 17:06:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Fabrice Gautier X-Mailer: iPhone Mail (13A340) In-Reply-To: <24527269-956F-4DFD-8801-1A5331DF0C20@gmail.com> Date: Thu, 3 Dec 2015 17:11:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3C789774-FF2C-4D27-B4A5-0D29E620A65E@gmail.com> References: <20151201210257.64f1a7a5@pc1> <1449051281.4345.31.camel@redhat.com> <24527269-956F-4DFD-8801-1A5331DF0C20@gmail.com> To: Yoav Nir Archived-At: Cc: "" Subject: Re: [TLS] Fresh results X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2015 01:07:00 -0000 > On Dec 3, 2015, at 12:47, Yoav Nir wrote: >=20 >=20 >> On 3 Dec 2015, at 8:40 PM, Fabrice Gautier wr= ote: >>=20 >> On Wed, Dec 2, 2015 at 2:14 AM, Nikos Mavrogiannopoulos = wrote: >>>> On Tue, 2015-12-01 at 21:02 +0100, Hanno B=C3=B6ck wrote: >>>> On Tue, 1 Dec 2015 14:28:49 -0500 >>>> Watson Ladd wrote: >>>>=20 >>>>> https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls >>>>> 13QuicAttacks.pdf >>>>>=20 >>>>> This one looks very nasty to fix. Short of disallowing the use of >>>>> RSA >>>>> certificates for TLS 1.2 with the RSA handshake and in TLS 1.3, I >>>>> don't see a good fix. I haven't read this paper in detail yet. >>>>>=20 >>>>> Cross-protocol attacks are the gift that keeps giving. >>>>=20 >>>> Correct me if I'm wrong, but as I understand the result (and I had >>>> one >>>> of the authors explaining it to me a few days ago) the problem >>>> appears >>>> only if you have a TLS 1.2 implementation with an RSA keyexchange >>>> that >>>> is vulnerable to a bleichenbacher attack. If it is not then you're >>>> fine. >>>=20 >>> The interesting result of the paper is: >>> "Even though this limits the >>> practical impact of this attack, it demonstrates that simply >>> removing a legacy algorithm from a standard is not necessarily >>> sufficient to protect against its weaknesses." >>>=20 >>> Even though the attack does not work for current implementations it >>> underlines that if you reuse keys from TLS 1.2 to TLS 1.3 you don't get >>> any advantage from the better algorithms in TLS 1.3. You are as safe, >>> as if you'd be using TLS 1.2. >>>=20 >>> That can be claimed to be trivial result given that it is underlined on >>> almost every paper that describes a cross-protocol attack, but it is >>> not still grasped by the engineering community. There have been >>> described quite some cross protocol attacks (Kerberos 4 -> Kerberos 5 >>> by Yu et al., TLS between ciphersuites starting by Wagner and >>> Schneier), but still we reuse keys between protocols. >>=20 >> Can we solve that problem generically by having TLS implementations >> use different certs for different TLS version, and have an indicator >> in the certs to indicate which version(s) they are for ? >=20 > That=E2=80=99s a heavy-handed approach that requires servers to have multi= ple certificates and new selection logic. Implementations already should have logic to select certificates based on SN= I, so that doesn't seem so far fetched especially in the context of adopting= TLS1.3. >=20 > Wouldn=E2=80=99t it be better to mandate that if your TLS implementation s= upports both TLS 1.2 and TLS 1.3 it should take actions necessary to mitigat= e the bleichenbacher attack? >=20 > In fact, if you don=E2=80=99t care much about very old browsers, isn=E2=80= =99t it possible today to mandate that the TLS implementation not use RSA ke= ying? That way the oracle is gone. Seems fine, for this specific attack, assuming you can ignore old clients an= d that your countermeasures are fully efficient. On the other hand, having two keys seems like it would counter any current a= nd future cross protocol attacks. >=20 > Seems better than requiring web server administrators to acquire two certi= ficates. >=20 > Yoav >=20 From nobody Thu Dec 3 19:04:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E8E1B2AB0 for ; Thu, 3 Dec 2015 19:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 a3OfB0EfJrln for ; Thu, 3 Dec 2015 19:04:02 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6D61B2AAF for ; Thu, 3 Dec 2015 19:04:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1449198242; x=1480734242; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OHmdX+u60byxy1ri20APQqHTEDtOKJSul2dizfeUykE=; b=M7dckb7cICQevpSmdTZ1ErthTvidLlkrE71PZJe1D/Kg/TDfGp1mjptS HmRHkVHx1KbhMD+Uuc7zHXjMPC1pmCMm1bS9s6viApOgbxyYDMw//8vQE mNqU4Z4G0hqhdGV9bilL0t+6nid14bcrVlUjqfkDbAg3efCwPQtae//A7 c0AVrOJKc7FajH9lT0Kqd7KaF8Az5JqoVZPb0yLF9rdn0vsWqnTSmPcVs w5bKB8RIZChgFyJtQ9j+oc/QLa+ZrUs9EGtf1+FlzQyxnrkQOEAV88FNs PYCPuUjD/sW8MP3CuItIHjARWpu/k4YBUUY7TVkD+UymBlQ11OcJMAHkq Q==; X-IronPort-AV: E=Sophos;i="5.20,378,1444647600"; d="scan'208";a="57590242" 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 mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 Dec 2015 16:03:57 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Fri, 4 Dec 2015 16:03:57 +1300 From: Peter Gutmann To: Jacob Appelbaum , "mrex@sap.com" Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all? Thread-Index: AQHRK9MuTTIrlxrBV0e1/10aVzchP560f84AgAB/gYCAAbsZAIAABeoAgAAQlACAAAryAIAAGvsAgAAGsYCAAAhOgIAAHVoAgAAPXYCAAGgdgIABChwAgABzXwCAARCr3g== Date: Fri, 4 Dec 2015 03:03:56 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B9865A@uxcn10-5.UoA.auckland.ac.nz> References: <20151203165344.C639C1A3A0@ld9781.wdf.sap.corp>, In-Reply-To: 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2015 03:04:06 -0000 Jacob Appelbaum writes:=0A= =0A= >TCP/IP and DNS are out of scope, though obviously related.=0A= =0A= Why are they out of scope? You can't just ignore a threat if it's=0A= inconvenient, you need to look at the overall picture. Arguing over pluggi= ng=0A= a mousehole in the corner of the barn is pointless when two of the four wal= ls=0A= are missing. As Martin has pointed out:=0A= =0A= There are so many ways and places where the servername WILL be leaked,=0A= (URLs, bookmarks, HTTP-Header-Fields, HTTP-Referer headers, etc.) that= =0A= bottom line, encrypting SNI amounts to crazy and pointless idea.=0A= =0A= I'm not sure if I'd call it crazy and pointless, just not worthwhile. You'= re=0A= leaking server-name information in a great many other locations and ways, a= nd=0A= encrypted SNIs causes so many problems, that the cost/benefit tradeoff does= n't=0A= make it worthwhile (which, I guess, could be classed as "pointless").=0A= =0A= Perhaps someone could write an RFC for a play-with-experimental-features TL= S=0A= extension, where implementers could encrypt lengths and SNIs and anything e= lse=0A= they want, and then test them out in the real world to see what effect it h= as.=0A= =0A= Peter.= From nobody Thu Dec 3 19:50:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56E21B2C90 for ; Thu, 3 Dec 2015 19:50:38 -0800 (PST) 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] 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 fHwYfDBmSKc1 for ; Thu, 3 Dec 2015 19:50:37 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC9F1B2C8D for ; Thu, 3 Dec 2015 19:50:37 -0800 (PST) Received: by ioc74 with SMTP id 74so103441232ioc.2 for ; Thu, 03 Dec 2015 19:50:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hgZkQ683GkjKWrdk1OdR6rnk3NgDHiuqkf9POBI/Y3A=; b=ouDEa9scKHT/Czda3dRYxiBAaaySdAPPoG1YFm63tiaEryDsr4x6GHxt9wCxQTwToK XvrDDV8/dl1w4PwMzwUcT8IIrI90FWIfStJco5VLEc5ivl4N52uJUL4oV1RTeCTBW5n2 i+Vu+sbgfMYb5XoiliN9jM9ttaCheRauVkG8OILbNcUAjf624fg1x9CAY+JOKOLMgYmn FiRtsfF5jUN36OaG/Svba4ulQMm4voZysYUIkoo3//NviL5BpIxJKLJMS5uz+BCpH/q2 OvHIEbZeRORfk2CzvRPiU+UXTh1TBIMYO4RsQs2e703y2p+n/+DuUI6XALxgwKqM7b62 QuuA== 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=hgZkQ683GkjKWrdk1OdR6rnk3NgDHiuqkf9POBI/Y3A=; b=AVxhy0VUvR6nZ+Xh5xrK6mNsyuRsozMvdhdn1NFXYLN1tvl+wIBpi5JA5jUoXOk11H s7WVUq0NfZeRjqZG25iYg7adEu/Z/GBro+jwV29z3RklbMqSiI5ky/haWWHX3LQr3tY+ mwenksh142vYqzmkqApQMW0q1aXapombK/0BokKgw26g7ODA97xa/OPdScp+FZjMblRd 3kJk/mWL/01JlBw0ARsSepZ3VbYsYQUYPSiX9sVr0ZUj5O8JaJyJtP3IPTqmozmzU2MF 43hD7aXXYu88ADTbfuADonY1Gkra/8GpUuB+OiBic7AhI6HKa+SMxIdydz9ddh+KoeIV U+Jg== X-Gm-Message-State: ALoCoQmLItMGdvwznFuMMP+4bVaGfevr1EAT+awb9gML8h/XRTs6lMfgOYkVX5LfgZ7bypoMTC6T MIME-Version: 1.0 X-Received: by 10.107.138.28 with SMTP id m28mr14337703iod.24.1449201036644; Thu, 03 Dec 2015 19:50:36 -0800 (PST) Received: by 10.79.70.71 with HTTP; Thu, 3 Dec 2015 19:50:36 -0800 (PST) X-Originating-IP: [109.163.234.2] In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B9865A@uxcn10-5.UoA.auckland.ac.nz> References: <20151203165344.C639C1A3A0@ld9781.wdf.sap.corp> <9A043F3CF02CD34C8E74AC1594475C73F4B9865A@uxcn10-5.UoA.auckland.ac.nz> Date: Fri, 4 Dec 2015 03:50:36 +0000 Message-ID: From: Jacob Appelbaum To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2015 03:50:38 -0000 On 12/4/15, Peter Gutmann wrote: > Jacob Appelbaum writes: > >>TCP/IP and DNS are out of scope, though obviously related. > > Why are they out of scope? They are out of scope for the TLS working group as far as I understand the organization of the IETF in terms of mandate. Am I incorrect? Should we discuss the privacy failures of IPv6 on this list as well? I'm happy to do so but I think this is out of scope. > You can't just ignore a threat if it's > inconvenient, you need to look at the overall picture. That is exactly what I've been saying over the last several days and really for many years. The collective action failures here are not because I can't see the overall picture but because there is blame shifting. If we look at one specific protocol and solve things, we find that composed with other solutions, we're really working toward an overall solution. > Arguing over > plugging > a mousehole in the corner of the barn is pointless when two of the four > walls > are missing. As Martin has pointed out: > > There are so many ways and places where the servername WILL be leaked, > (URLs, bookmarks, HTTP-Header-Fields, HTTP-Referer headers, etc.) that > bottom line, encrypting SNI amounts to crazy and pointless idea. TLS protects the HTTP headers, bookmarks don't travel across the network and a url needs to be sent by a protocol to be leaked to the network. The client requested hostname is leaked a single time. Plugging that leak by encrypting it is not impossible and that someone might share a URL doesn't mitigate the usefulness of reducing that specific information leakage in TLS. The point is not to hide that a server has a name - the point is to protect a flow within a relevant time frame. This may prevent an adversary from selecting it for storage (ex: XKeyscore selector on cs.auckland.ac.nz) or it may prevent an adversary from doing an active attack from even as lowly as an off-path position having seen just a single or small subset of packets from a given flow. There are other reasons as well. That DNS has problems doesn't mitigate that TLS itself has problems when it stands alone. > > I'm not sure if I'd call it crazy and pointless, just not worthwhile. > You're > leaking server-name information in a great many other locations and ways, > and > encrypted SNIs causes so many problems, that the cost/benefit tradeoff > doesn't > make it worthwhile (which, I guess, could be classed as "pointless"). As a TLS user - I'm only leaking SNI at Tor exit nodes and there is no other choice for me. I'm living in the world where DNS and other channels are not leaking on the same path as my TLS connection. Still, my TLS connections have a lot of information that is available to a sniffer on a Tor exit or XKeyscore on the whole internet. Removal of the SNI field is not an option - encrypting it should be an option, if not a strong default. > > Perhaps someone could write an RFC for a play-with-experimental-features TLS > extension, where implementers could encrypt lengths and SNIs and anything > else > they want, and then test them out in the real world to see what effect it > has. Or they could just call MinimaLT or CurveCP with mandatory Elligator TLS 1.3 and be done with it. All the best, Jacob From nobody Thu Dec 3 20:21:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A631B2A1D for ; Thu, 3 Dec 2015 20:21:01 -0800 (PST) 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, HTML_MESSAGE=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 l6gxoAdD8jKN for ; Thu, 3 Dec 2015 20:21:00 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6A91B2A19 for ; Thu, 3 Dec 2015 20:21:00 -0800 (PST) Received: by ykdr82 with SMTP id r82so111257904ykd.3 for ; Thu, 03 Dec 2015 20:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cjaV9i8qbwQLpWxd5fkdL7VNV37N5h54etsNJE058Ww=; b=BQsY6xzuDhKikn4hX7wFlFQZB1Js6XXJM0z9fLemhu+tiZTNjJNS0p67k49P707tMv HfphtTi4gZqOCpwc3FbN7fQz6Vgzi2ThX4K4il4uSgMTHfCCuigf//PXwsmjOmD5BcsP D90PShE3IhFkBVAtH0Lj5RbD88eOA+jdFtbr0/ZtY8NteRARgDePotdRrAqGbU7wq+ht 78vrenjvP7sImG8/NtbZtzPLoCP9FxOAPFjmYoDHT4cWr9fyJskm+B9B49yh9PFMOpLt bFj1l9QOn1dXpW9rZoLWZT7iuB6QovpvH7zuDv4InTV/ANXDULBGGLtD/MQ675f4QYix KkVw== 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=cjaV9i8qbwQLpWxd5fkdL7VNV37N5h54etsNJE058Ww=; b=kozxO0NrfgGj+hRKm5WR+g29ZzhPOPV0jdpAbSV1vuXvzJY4bvUc+U6bENJre8CIke EHUJuXwRlGvfS3hEN562i1BMHtwt+p1+pCD/yqrbB5d4tPiHD0DElqXppX6EFYQBK5ev fU3NzBt7MM9WB8BS25q9pBKROHEcg7HyTlcGdPBKFBa9DP2JE845Btf2dSd8Pid5eNW6 KQxAdiyP+8nfLWJ+0Lp4ju3xdAMtUdSZzXT4+pXCyEogJZe8bCOgWFlXcWBxlGQb+xTz AEfATm/faE8HErq0SurFrIEcfeQnArC+uwIpC9MOpyQjL59nMm6X2uTSPzkNM0WK+kFW d4VA== X-Gm-Message-State: ALoCoQnxXlwuLPVPnSfd8cmIwKCYwNQnqdhfOBLegaIIgPtSvOrvem/somHPF39lsOr0HjAc4AHt X-Received: by 10.129.34.4 with SMTP id i4mr9478516ywi.155.1449202859320; Thu, 03 Dec 2015 20:20:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Thu, 3 Dec 2015 20:20:19 -0800 (PST) In-Reply-To: <20151202192308.GA25802@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151201185733.GB15222@LK-Perkele-V2.elisa-laajakaista.fi> <20151202170845.GA25111@LK-Perkele-V2.elisa-laajakaista.fi> <20151202192308.GA25802@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Thu, 3 Dec 2015 20:20:19 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11408678a3572105260ad552 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft status and updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2015 04:21:01 -0000 --001a11408678a3572105260ad552 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 2, 2015 at 11:23 AM, Ilari Liusvaara wrote: > > > > > Trying to read between the lines, is your concern that the server is > > > > now no longer explicitly signing over the ServerConfiguration in > > > > its CertificateVerify [Note that the client continues to do so]? The > idea > > > > behind removing that was to make the 1-RTT part of the handshake > > > > more uniform regardless of whether 0-RTT data was used. > > > > I'm certainly open to putting that back in if it's needed, but can > you > > > > explain your concern in more detail? > > > > > > The concern is that attacker that has managed to inject g^s for > > > known s is able to impersonate the server even through server > certificate > > > validation on subsequent connections (under some conditions). > > > > > > > I'm sorry, I'm still not following. All the data that the server sends is > > tied to > > g^y which is signed with the server's certificate, so even if s were > > published, > > the attacker should not be able to inject data which the client would > > accept. > > I would certainly expect the signature check, if it is there at all, to > be proper nonce over SS. > > IIRC, the key exchange is explicitly intended to be secure (but forward > security is lost) if ES is revealed. > > Config-authenticated ciphersuites are different matter (the main > challenge there seems to be deciding when those are to be enabled[1], > not so much designing the key exchange[2]). > I may be being stupid, but I think I'm still not following. Do you think you could provide a ladder diagram showing the messages that demonstrate the attack you are concerned about. Best, -Ekr --001a11408678a3572105260ad552 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 2, 2015 at 11:23 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:

> > > Trying to read between the lines, is your concern that the s= erver is
> > > now no longer explicitly signing over the ServerConfiguratio= n in
> > > its CertificateVerify [Note that the client continues to do = so]? The idea
> > > behind removing that was to make the 1-RTT part of the hands= hake
> > > more uniform regardless of whether 0-RTT data was used.
> > > I'm certainly open to putting that back in if it's n= eeded, but can you
> > > explain your concern in more detail?
> >
> > The concern is that attacker that has managed to inject g^s for > > known s is able to impersonate the server even through server cer= tificate
> > validation on subsequent connections (under some conditions).
> >
>
> I'm sorry, I'm still not following. All the data that the serv= er sends is
> tied to
> g^y which is signed with the server's certificate, so even if s we= re
> published,
> the attacker should not be able to inject data which the client would<= br> > accept.

I would certainly expect the signature check, if it is there at all,= to
be proper nonce over SS.

IIRC, the key exchange is explicitly intended to be secure (but forward
security is lost) if ES is revealed.

Config-authenticated ciphersuites are different matter (the main
challenge there seems to be deciding when those are to be enabled[1],
not so much designing the key exchange[2]).

=
I may be being stupid, but I think I'm still not following. Do you= think
you could provide a ladder diagram showing the messages th= at
demonstrate the attack you are concerned about.

=
Best,
-Ekr
--001a11408678a3572105260ad552-- From nobody Thu Dec 3 22:41:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4451B2DF7 for ; Thu, 3 Dec 2015 22:41:24 -0800 (PST) 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_BACK=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 85VCp7HWjKyq for ; Thu, 3 Dec 2015 22:41:22 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D381B2DF6 for ; Thu, 3 Dec 2015 22:41:21 -0800 (PST) Received: by wmww144 with SMTP id w144so51849470wmw.0 for ; Thu, 03 Dec 2015 22:41:20 -0800 (PST) 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 :message-id:references:to; bh=OVxE38RWJiLyGR83VC3C/yVytf5SWXfWdNz7TZQo3jY=; b=CMu3I3uOOE1A7oOKpLkSC3YwBfjTfOMam22vb3sWUFWUNNlf3JIydjQrCA0r/S3Utf eAMAJ4xyyZZMXi5Uy0pMTFbyuO4cCK95mTvhAkmhnPJhTusHK8AAzf7NIR2UeduOS5cs 5Tb98cxqBl5BsWaY3HSUUu5p65CI6Ny6dXKWFRU4nxbUwQ7KU8T6JkT0WN3qdtcPPOdJ Bc669HBHCY1ECHINQSF1FlWNWKFrNOphDbfCBoFjS/AgjsjY5eLy70NzWWKYniUl6+x0 AKWaQ9L6q3HO0aiMGUWYMJ6EaqXTtjEKaQXe2rraoR8iUA4g3flgiWESXJ14OXbdjtVi Y6mQ== X-Received: by 10.194.7.230 with SMTP id m6mr15198931wja.124.1449211280108; Thu, 03 Dec 2015 22:41:20 -0800 (PST) Received: from [192.168.0.12] (89-156-8-219.rev.numericable.fr. [89.156.8.219]) by smtp.gmail.com with ESMTPSA id q9sm10708464wjo.9.2015.12.03.22.41.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Dec 2015 22:41:18 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_AA136A2F-F2E0-4454-AF66-EC99AFD6D82A" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Karthikeyan Bhargavan In-Reply-To: <3C789774-FF2C-4D27-B4A5-0D29E620A65E@gmail.com> Date: Fri, 4 Dec 2015 07:41:16 +0100 Message-Id: <8C9182C4-A92E-4FE0-9576-87007CCE75A7@gmail.com> References: <20151201210257.64f1a7a5@pc1> <1449051281.4345.31.camel@redhat.com> <24527269-956F-4DFD-8801-1A5331DF0C20@gmail.com> <3C789774-FF2C-4D27-B4A5-0D29E620A65E@gmail.com> To: Fabrice Gautier X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "" Subject: Re: [TLS] Fresh results X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2015 06:41:24 -0000 --Apple-Mail=_AA136A2F-F2E0-4454-AF66-EC99AFD6D82A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The use of the same RSA key for decryption and signature has always been=20= problematic from a cryptographic point of view. As far as I am aware, = all current security theorems for TLS assume that the same RSA certificate = (public key)=20 is not used in both RSA and DHE ciphersuites.=20 In theory this should be enforced by KeyUsage, there are distinct = KeyUsages for public key encryption and digital signatures and we may require that = DHE/ECDHE ciphersuites must use certificates that *do not* enable public key = encryption, and that clients must enforce this behavior. Of course, the current practice is that KeyUsage is ignored. OpenSSL = will take a certificate that only specified Public Key Encryption and happily = use and accept it for digital signature. Similar flexibility allows ECDSA = certs that should only be used for signing to be used for static ECDH key exchange = (leading to other vulnerabilities). Do we (as in the TLS working group) have the = necessary influence to make sure that KeyUsage is respected? > On 04 Dec 2015, at 02:11, Fabrice Gautier = wrote: >=20 >>=20 >> On Dec 3, 2015, at 12:47, Yoav Nir wrote: >>=20 >>=20 >>> On 3 Dec 2015, at 8:40 PM, Fabrice Gautier = wrote: >>>=20 >>> On Wed, Dec 2, 2015 at 2:14 AM, Nikos Mavrogiannopoulos = wrote: >>>>> On Tue, 2015-12-01 at 21:02 +0100, Hanno B=C3=B6ck wrote: >>>>> On Tue, 1 Dec 2015 14:28:49 -0500 >>>>> Watson Ladd wrote: >>>>>=20 >>>>>> = https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls >>>>>> 13QuicAttacks.pdf >>>>>>=20 >>>>>> This one looks very nasty to fix. Short of disallowing the use of >>>>>> RSA >>>>>> certificates for TLS 1.2 with the RSA handshake and in TLS 1.3, I >>>>>> don't see a good fix. I haven't read this paper in detail yet. >>>>>>=20 >>>>>> Cross-protocol attacks are the gift that keeps giving. >>>>>=20 >>>>> Correct me if I'm wrong, but as I understand the result (and I had >>>>> one >>>>> of the authors explaining it to me a few days ago) the problem >>>>> appears >>>>> only if you have a TLS 1.2 implementation with an RSA keyexchange >>>>> that >>>>> is vulnerable to a bleichenbacher attack. If it is not then you're >>>>> fine. >>>>=20 >>>> The interesting result of the paper is: >>>> "Even though this limits the >>>> practical impact of this attack, it demonstrates that = simply >>>> removing a legacy algorithm from a standard is not necessarily >>>> sufficient to protect against its weaknesses." >>>>=20 >>>> Even though the attack does not work for current implementations it >>>> underlines that if you reuse keys from TLS 1.2 to TLS 1.3 you don't = get >>>> any advantage from the better algorithms in TLS 1.3. You are as = safe, >>>> as if you'd be using TLS 1.2. >>>>=20 >>>> That can be claimed to be trivial result given that it is = underlined on >>>> almost every paper that describes a cross-protocol attack, but it = is >>>> not still grasped by the engineering community. There have been >>>> described quite some cross protocol attacks (Kerberos 4 -> Kerberos = 5 >>>> by Yu et al., TLS between ciphersuites starting by Wagner and >>>> Schneier), but still we reuse keys between protocols. >>>=20 >>> Can we solve that problem generically by having TLS implementations >>> use different certs for different TLS version, and have an indicator >>> in the certs to indicate which version(s) they are for ? >>=20 >> That=E2=80=99s a heavy-handed approach that requires servers to have = multiple certificates and new selection logic. >=20 > Implementations already should have logic to select certificates based = on SNI, so that doesn't seem so far fetched especially in the context of = adopting TLS1.3. >=20 >>=20 >> Wouldn=E2=80=99t it be better to mandate that if your TLS = implementation supports both TLS 1.2 and TLS 1.3 it should take actions = necessary to mitigate the bleichenbacher attack? >>=20 >> In fact, if you don=E2=80=99t care much about very old browsers, = isn=E2=80=99t it possible today to mandate that the TLS implementation = not use RSA keying? That way the oracle is gone. >=20 > Seems fine, for this specific attack, assuming you can ignore old = clients and that your countermeasures are fully efficient. >=20 > On the other hand, having two keys seems like it would counter any = current and future cross protocol attacks. >=20 >>=20 >> Seems better than requiring web server administrators to acquire two = certificates. >>=20 >> Yoav >>=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = --Apple-Mail=_AA136A2F-F2E0-4454-AF66-EC99AFD6D82A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The use of the same RSA key for decryption and signature has = always been 
problematic from a cryptographic point = of view. As far as I am aware, all
current security = theorems for TLS assume that the same RSA certificate (public = key) 
is not used in both RSA and DHE = ciphersuites. 

In theory this should be enforced by KeyUsage, there are = distinct KeyUsages
for public key encryption and = digital signatures and we may require that DHE/ECDHE
ciphersuites must use certificates that *do not* enable = public key encryption,
and that clients must = enforce this behavior.

Of course, the current practice is that KeyUsage is ignored. = OpenSSL will
take a certificate that only specified = Public Key Encryption and happily use
and accept it = for digital signature. Similar flexibility allows ECDSA certs = that
should only be used for signing to be used for = static ECDH key exchange (leading
to other = vulnerabilities). Do we (as in the TLS working group) have the = necessary
influence to make sure that KeyUsage is = respected?

On = 04 Dec 2015, at 02:11, Fabrice Gautier <fabrice.gautier@gmail.com> wrote:


On Dec 3, 2015, at 12:47, Yoav Nir = <ynir.ietf@gmail.com> wrote:


On 3 Dec = 2015, at 8:40 PM, Fabrice Gautier <fabrice.gautier@gmail.com> wrote:

On Wed, Dec 2, 2015 at 2:14 AM, Nikos Mavrogiannopoulos = <nmav@redhat.com> = wrote:
On Tue, 2015-12-01 at 21:02 +0100, Hanno B=C3=B6c= k wrote:
On Tue, 1 Dec 2015 14:28:49 -0500
Watson Ladd <watsonbladd@gmail.com> wrote:

https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21= /Tls
13QuicAttacks.pdf

This= one looks very nasty to fix. Short of disallowing the use of
RSA
certificates for TLS 1.2 with the RSA = handshake and in TLS 1.3, I
don't see a good fix. I = haven't read this paper in detail yet.

Cross-protocol attacks are the gift that keeps giving.

Correct me if I'm wrong, but as I = understand the result (and I had
one
of the = authors explaining it to me a few days ago) the problem
appears
only if you have a TLS 1.2 = implementation with an RSA keyexchange
that
is= vulnerable to a bleichenbacher attack. If it is not then you're
fine.

The = interesting result of the paper is:
"Even though this = limits the
practical  impact  of  this =  attack,  it  demonstrates  that  simply
removing a legacy algorithm from a standard is not = necessarily
sufficient to protect against its = weaknesses."

Even though the attack does = not work for current implementations it
underlines that if = you reuse keys from TLS 1.2 to TLS 1.3 you don't get
any = advantage from the better algorithms in TLS 1.3. You are as safe,
as if you'd be using TLS 1.2.

That= can be claimed to be trivial result given that it is underlined on
almost every paper that describes a cross-protocol attack, = but it is
not still grasped by the engineering community. = There have been
described quite some cross protocol = attacks (Kerberos 4 -> Kerberos 5
by Yu et al., TLS = between ciphersuites starting by Wagner and
Schneier), but = still we reuse keys between protocols.

Can we solve that problem generically by having TLS = implementations
use different certs for different TLS = version, and have an indicator
in the certs to indicate = which version(s) they are for ?

That=E2=80=99s a heavy-handed approach that requires servers = to have multiple certificates and new selection logic.

Implementations already should have logic to = select certificates based on SNI, so that doesn't seem so far fetched = especially in the context of adopting TLS1.3.


Wouldn=E2=80=99t it be better to mandate that if your TLS = implementation supports both TLS 1.2 and TLS 1.3 it should take actions = necessary to mitigate the bleichenbacher attack?

In fact, if you don=E2=80=99t care much about very old = browsers, isn=E2=80=99t it possible today to mandate that the TLS = implementation not use RSA keying? That way the oracle is gone.

Seems fine, for this specific attack, assuming = you can ignore old clients and that your countermeasures are fully = efficient.

On the other hand, having = two keys seems like it would counter any current and future cross = protocol attacks.


Seems better = than requiring web server administrators to acquire two certificates.

Yoav


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

= --Apple-Mail=_AA136A2F-F2E0-4454-AF66-EC99AFD6D82A-- From nobody Thu Dec 3 22:56:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE1C1B2E27 for ; Thu, 3 Dec 2015 22:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 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, RCVD_IN_SORBS_WEB=0.77, 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 hLB1zuOFGFtW for ; Thu, 3 Dec 2015 22:56:35 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E211B2E25 for ; Thu, 3 Dec 2015 22:56:34 -0800 (PST) Received: by lbbkw15 with SMTP id kw15so15118144lbb.0 for ; Thu, 03 Dec 2015 22:56:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type; bh=Kf1WCWm4NzGc7XoZvTRWN5oIRIVkQSRkToZ99oFykyU=; b=hJIwuS0LoYriTtWIEEQYXuhqS01oajPNAnCu//HkUnkIUNAqlwBxfoeO7u9vuiUe4n C4hU/nCTz3qP7Sx/Q7k7Vsu3/9PfdwbTumXdRrZsjVRjIpgawhuFst32sapNqmWr+aBk of/iPOvnYxCl0XH03tXwPk+MKEFxWvKP/wKQCBpesPeKBbwENcN+/fN1Nq35CahxQwCp QfZ5+EQJmNL3LDMihu5fq2lyvOMkzQIh/qZsNWYOBkC+/MXjcrJ/613ilhp5Fbxi78Uh RlAFCrFBeombhstpJZJIQk/6AVQ51TqLmQkgppLzSYdejb4imRRtwITVm8tjU5e9umfp iqPw== X-Received: by 10.112.147.229 with SMTP id tn5mr7274296lbb.47.1449212192721; Thu, 03 Dec 2015 22:56:32 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id d203sm2014870lfg.39.2015.12.03.22.56.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Dec 2015 22:56:31 -0800 (PST) Message-ID: <7F6CAD8F92F54AD5A4F6B14D5F471740@buildpc> From: "Valery Smyslov" To: "Bryan Ford" , "Dmitry Belyavsky" References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> <565E1517.3060209@gmail.com> <9BDDC23D-1039-4C75-BF32-57330317BCAB@gmail.com> Date: Fri, 4 Dec 2015 09:56:29 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0BA6_01D12E7A.0C5D3D60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2015 06:56:37 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0BA6_01D12E7A.0C5D3D60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bryan, I guess Dmitry is talking about the trick when each datagram is = encrypted with its own key,=20 derived from the "master" session key using some unique public parameter = of the datagram, like its sequence_number. This trick makes attacks on encryption key = almost useless. It is not specifically bound to GOST cipher, however it is sometimes = used with this cipher=20 to deal with its short (by current standards) block size. See for = example the (now expired) draft=20 https://www.ietf.org/archive/id/draft-fedchenko-ipsecme-cpesp-gost-04.txt= (it is about ESP, but the general principles are the same for DTLS). As far as I understand your proposal makes impossible to use this trick, = if we consider packets loss and reordering. Regards, Valery Smyslov. From: Bryan Ford=20 To: Dmitry Belyavsky=20 Cc: tls@ietf.org=20 Sent: Wednesday, December 02, 2015 12:11 PM Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: = Encrypting record headers: practical for TLS 1.3 after all?) On 02 Dec 2015, at 09:42, Dmitry Belyavsky wrote: On Wed, Dec 2, 2015 at 12:45 AM, Bryan A Ford = wrote: On 12/1/15 9:49 PM, Dmitry Belyavsky wrote: > Dear Bryan, > > DTLS: > > Now there's still the important question of whether this = (new) proposal > could be made to work in the context of DTLS. For the DTLS = case, my > current thinking is that some elements of my earlier = proposal is > probably more suitable: namely using a stream cipher (or = AEAD used as a > stream cipher) to encrypt and recognize the = explicitly-transmitted > sequence numbers that DTLS needs. This could operate = basically the same > as I described in my earlier E-mail on this topic. Note = that the length > field is no longer a problem in DTLS as it is in TLS, = because the > receiver already gets the length of the datagram from UDP. > > > Do I understand correctly that your propose makes difficult to = derive > the key from the original value depending on the sequence = number? I'm not sure I understand your question; can you clarify? What is = the "original value" you are worried about the key being derivable = from? Certainly if the cipher (stream cipher or AEAD) is working = correctly, it should make it cryptographically infeasible for an attacker to = derive the shared secret key from anything the protocol transmits. I mean something like http://tools.ietf.org/html/rfc4357#section-7 We have the keys calculated during the handshake and want to modify = it for each record.=20 Hmmm - the RFC you point to is about the GOST cipher, and section 7 = seems to be about =E2=80=9Csecret key diversification=E2=80=9D, but I = know nothing about GOST other than that it=E2=80=99s a cipher and = it=E2=80=99s not obvious to me what exactly =E2=80=9Csecret key = diversification=E2=80=9D means here or what exactly it has to do with = TLS (which works with many different ciphers). I guess I still need a = more detailed clarification of your question if I=E2=80=99m going to be = able to try to answer it. B --=20 SY, Dmitry Belyavsky -------------------------------------------------------------------------= ----- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ------=_NextPart_000_0BA6_01D12E7A.0C5D3D60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi Bryan,
 
I guess Dmitry is talking about the trick when each = datagram=20 is encrypted with its own key,
derived from the "master" session key using some = unique public=20 parameter of the datagram,
like its sequence_number. This trick makes = attacks on=20 encryption key almost useless.
It is not specifically bound to GOST cipher, however = it is=20 sometimes used with this = cipher 
to deal with its short (by current standards) block = size.=20 See for example the (now expired) draft =
https://www.ietf.org/archive/id/draft-fedchenko-ipsecme-cpesp-g= ost-04.txt
(it is about ESP, but the = general principles are the=20 same for DTLS).
 
As far as I understand your proposal makes = impossible to use=20 this trick,
if we consider packets loss = and=20 reordering.
 
Regards,
Valery Smyslov.
 
From:=20 Bryan=20 Ford
Sent: Wednesday, December 02, = 2015 12:11=20 PM
Subject: Re: [TLS] Fully = encrypted and=20 authenticated headers (was Re: Encrypting record headers: practical = for TLS=20 1.3 after all?)

On 02 Dec 2015, at 09:42, Dmitry Belyavsky <beldmit@gmail.com> wrote:
On Wed, Dec 2, 2015 at 12:45 AM, Bryan A = Ford <brynosaurus@gmail.com> wrote:
On 12/1/15 9:49 PM, Dmitry Belyavsky=20 wrote:
> Dear Bryan,
>
>  =  =20  DTLS:
>
>     Now there's still = the=20 important question of whether this (new) proposal
>  =  =20  could be made to work in the context of DTLS.  For the = DTLS=20 case, my
>     current thinking is that some = elements=20 of my earlier proposal is
>     probably more = suitable: namely using a stream cipher (or AEAD used as = a
> =20    stream cipher) to encrypt and recognize the=20 explicitly-transmitted
>     sequence numbers = that=20 DTLS needs.  This could operate basically the = same
> =20    as I described in my earlier E-mail on this = topic.  Note=20 that the length
>     field is no longer a = problem in=20 DTLS as it is in TLS, because the
>    =  receiver=20 already gets the length of the datagram from = UDP.
>
>
>=20 Do I understand correctly that your propose makes difficult to=20 derive
> the key from the original value depending on the = sequence=20 number?

I'm not sure I understand your question; can = you=20 clarify?  What is the
"original value" you are worried = about the=20 key being derivable from?
Certainly if the cipher (stream = cipher or=20 AEAD) is working correctly, it
should make it cryptographically = infeasible for an attacker to derive
the shared secret key from = anything the protocol transmits.

I mean something like http://tools.ietf.o= rg/html/rfc4357#section-7
We have the keys calculated during the handshake and want to = modify it=20 for each record. 

Hmmm - the RFC you point to is about the GOST cipher, and section = 7 seems=20 to be about =E2=80=9Csecret key diversification=E2=80=9D, but I know = nothing about GOST other=20 than that it=E2=80=99s a cipher and it=E2=80=99s not obvious to me = what exactly =E2=80=9Csecret key=20 diversification=E2=80=9D means here or what exactly it has to do with = TLS (which works=20 with many different ciphers).  I guess I still need a more = detailed=20 clarification of your question if I=E2=80=99m going to be able to try = to answer=20 it.

B



--
SY, Dmitry=20 Belyavsky

_______________________________________________
TLS mailing=20 = list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
------=_NextPart_000_0BA6_01D12E7A.0C5D3D60-- From nobody Thu Dec 3 23:01:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CC91B2E33 for ; Thu, 3 Dec 2015 23:01:22 -0800 (PST) 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 blJ0m8uH6Rue for ; Thu, 3 Dec 2015 23:01:20 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7731B2E29 for ; Thu, 3 Dec 2015 23:01:20 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6351E284E33; Fri, 4 Dec 2015 07:01:19 +0000 (UTC) Date: Fri, 4 Dec 2015 07:01:19 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151204070119.GQ18315@mournblade.imrryr.org> References: <20151201210257.64f1a7a5@pc1> <1449051281.4345.31.camel@redhat.com> <24527269-956F-4DFD-8801-1A5331DF0C20@gmail.com> <3C789774-FF2C-4D27-B4A5-0D29E620A65E@gmail.com> <8C9182C4-A92E-4FE0-9576-87007CCE75A7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C9182C4-A92E-4FE0-9576-87007CCE75A7@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Fresh results 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, 04 Dec 2015 07:01:23 -0000 On Fri, Dec 04, 2015 at 07:41:16AM +0100, Karthikeyan Bhargavan wrote: > Of course, the current practice is that KeyUsage is ignored. OpenSSL will > take a certificate that only specified Public Key Encryption and happily use > and accept it for digital signature. Similar flexibility allows ECDSA certs that > should only be used for signing to be used for static ECDH key exchange (leading > to other vulnerabilities). Do we (as in the TLS working group) have the necessary > influence to make sure that KeyUsage is respected? Suppose keyUsage is respected. Who will knowingly shoot themselves in the foot and restrict their RSA certificate to just DHE or just RSA key transport? This looks like an impractical counter-measure. And by the way key usage is enforced by OpenSSL for EC. $ git grep -C3 X509v3_KU_ ssl ssl/ssl_lib.c- X509_check_purpose(x, -1, 0); ssl/ssl_lib.c-# ifndef OPENSSL_NO_ECDH ssl/ssl_lib.c- ecdh_ok = (x->ex_flags & EXFLAG_KUSAGE) ? ssl/ssl_lib.c: (x->ex_kusage & X509v3_KU_KEY_AGREEMENT) : 1; ssl/ssl_lib.c-# endif ssl/ssl_lib.c- ecdsa_ok = (x->ex_flags & EXFLAG_KUSAGE) ? ssl/ssl_lib.c: (x->ex_kusage & X509v3_KU_DIGITAL_SIGNATURE) : 1; ssl/ssl_lib.c- if (!(cpk->valid_flags & CERT_PKEY_SIGN)) ssl/ssl_lib.c- ecdsa_ok = 0; ssl/ssl_lib.c- ecc_pkey = X509_get_pubkey(x); -- ssl/ssl_lib.c- } ssl/ssl_lib.c- if (alg_k & SSL_kECDHe || alg_k & SSL_kECDHr) { ssl/ssl_lib.c- /* key usage, if present, must allow key agreement */ ssl/ssl_lib.c: if (ku_reject(x, X509v3_KU_KEY_AGREEMENT)) { ssl/ssl_lib.c- SSLerr(SSL_F_SSL_CHECK_SRVR_ECC_CERT_AND_ALG, ssl/ssl_lib.c- SSL_R_ECC_CERT_NOT_FOR_KEY_AGREEMENT); ssl/ssl_lib.c- return 0; -- ssl/ssl_lib.c- } ssl/ssl_lib.c- if (alg_a & SSL_aECDSA) { ssl/ssl_lib.c- /* key usage, if present, must allow signing */ ssl/ssl_lib.c: if (ku_reject(x, X509v3_KU_DIGITAL_SIGNATURE)) { ssl/ssl_lib.c- SSLerr(SSL_F_SSL_CHECK_SRVR_ECC_CERT_AND_ALG, ssl/ssl_lib.c- SSL_R_ECC_CERT_NOT_FOR_SIGNING); ssl/ssl_lib.c- return 0; -- Viktor. From nobody Fri Dec 4 01:26:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708111A036D for ; Fri, 4 Dec 2015 01:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 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, HELO_EQ_FR=0.35, 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 fOULy-DVG5pc for ; Fri, 4 Dec 2015 01:26:26 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BE8D1A0252 for ; Fri, 4 Dec 2015 01:26:26 -0800 (PST) Received: by wmww144 with SMTP id w144so56709502wmw.0 for ; Fri, 04 Dec 2015 01:26:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:message-id :references:to; bh=zObkN9FWVA8tki0DdCDMLAY8IGj+Y/9r49yk1p/CYtU=; b=Pp9eQ5pPgVjkFNC/lmQD3Wp9gxXpHFfXoHG2U4tPSEs08N1RWTtyx8LqAT0V9WHX2I EjMSzsRjuI6yd5pqsvIbGwAotvYGhRkJ/X90048+Uyc/tNgItrBMlL6uKP3V/27Jx6df C/OPfYN5FiYIGNJu16MikLAklwdR1OO94/tvIf6NF957T1ZrYMMQl4S3dGM1ozxfaRbu 2lUk3GN52cjmXTjAsQIwpyjAkPDgDtO4yl8/XvOiivO5Spw/DF5pEJlWfrRBzPi40zZX xY5KgVSpib5cEe/N3p/tlMhrkN/Key8TZdzKd14noCyV2WZW7IapZfqagvxxU1AW0nyZ LG3w== X-Received: by 10.194.178.202 with SMTP id da10mr15741316wjc.158.1449221184612; Fri, 04 Dec 2015 01:26:24 -0800 (PST) Received: from wifi-auth-191208.inria.fr (wifi-auth-191208.inria.fr. [128.93.191.208]) by smtp.gmail.com with ESMTPSA id ft4sm11158393wjb.37.2015.12.04.01.26.22 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 04 Dec 2015 01:26:23 -0800 (PST) From: Karthikeyan Bhargavan X-Google-Original-From: Karthikeyan Bhargavan Content-Type: multipart/signed; boundary="Apple-Mail=_4AC37C81-D2F1-4056-A064-FFCA0CDD008B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Pgp-Agent: GPGMail 2.6b2 In-Reply-To: <20151204070119.GQ18315@mournblade.imrryr.org> Date: Fri, 4 Dec 2015 10:26:21 +0100 Message-Id: <4C7A35C8-7ECF-4E31-BD57-0ECDDED36273@inria.fr> References: <20151201210257.64f1a7a5@pc1> <1449051281.4345.31.camel@redhat.com> <24527269-956F-4DFD-8801-1A5331DF0C20@gmail.com> <3C789774-FF2C-4D27-B4A5-0D29E620A65E@gmail.com> <8C9182C4-A92E-4FE0-9576-87007CCE75A7@gmail.com> <20151204070119.GQ18315@mournblade.imrryr.org> To: tls@ietf.org X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: Re: [TLS] Fresh results X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2015 09:26:28 -0000 --Apple-Mail=_4AC37C81-D2F1-4056-A064-FFCA0CDD008B Content-Type: multipart/alternative; boundary="Apple-Mail=_29DD6A1E-1105-48A2-8AD5-A771E347A4ED" --Apple-Mail=_29DD6A1E-1105-48A2-8AD5-A771E347A4ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Suppose keyUsage is respected. Who will knowingly shoot themselves > in the foot and restrict their RSA certificate to just DHE or just > RSA key transport? This looks like an impractical counter-measure. I guess we have to trade-off between different levels of =E2=80=9Cshooting= oneself in the foot=E2=80=9D. For a company that has a bunch of certificates, one for each domain, = separate ECDSA and RSA certificates etc. spending a few more dollars on different certs for RSA encryption does = not seem like a lot. In any case, the main issue is whether we can get recipients to enforce = key usage, not senders. If a cert explicitly enables key exchange, encryption, and signature, it = can be used for all of these. However, if the cert restricts itself to digital signature, then the = client should not use it for RSA encryption. That way, the server gets to choose whether it wants protection from = cross-protocol attacks or not, and the client will enforce its wishes correctly. Regarding ECDSA->ECDH cross-protocol attacks, the code that you pointed = out in OpenSSL indeed allows the server to ensure it does not use a sign-only cert for ECDH, = but other libraries do not make this distinction. Moreover, as far as I know, OpenSSL clients do not enforce this key = usage restriction (See crypto/x509/x509type.c for the certificate usage = rules.) Neither, for that matter do other TLS clients like NSS etc. This allows = attacks like the ECDH downgrade in [1] and can probably make the ECDSA key recovery attack in [2] quite = a bit worse. =46rom the viewpoint of provable security, I=E2=80=99d be suspicious of = any TLS modes that allow the same long-term keys to be used in multiple different ways. For RSA/EC, there = are known attacks. But even otherwise, their use requires a strong joint security assumption that we don=E2=80=99= t really know how to justify. -K. [1] https://www.smacktls.com/smack.pdf = [2] http://euklid.org/pdf/ECC_Invalid_Curve.pdf = >=20 > And by the way key usage is enforced by OpenSSL for EC. >=20 > $ git grep -C3 X509v3_KU_ ssl > ssl/ssl_lib.c- X509_check_purpose(x, -1, 0); > ssl/ssl_lib.c-# ifndef OPENSSL_NO_ECDH > ssl/ssl_lib.c- ecdh_ok =3D (x->ex_flags & EXFLAG_KUSAGE) ? > ssl/ssl_lib.c: (x->ex_kusage & X509v3_KU_KEY_AGREEMENT) = : 1; > ssl/ssl_lib.c-# endif > ssl/ssl_lib.c- ecdsa_ok =3D (x->ex_flags & EXFLAG_KUSAGE) ? > ssl/ssl_lib.c: (x->ex_kusage & = X509v3_KU_DIGITAL_SIGNATURE) : 1; > ssl/ssl_lib.c- if (!(cpk->valid_flags & CERT_PKEY_SIGN)) > ssl/ssl_lib.c- ecdsa_ok =3D 0; > ssl/ssl_lib.c- ecc_pkey =3D X509_get_pubkey(x); > -- > ssl/ssl_lib.c- } > ssl/ssl_lib.c- if (alg_k & SSL_kECDHe || alg_k & SSL_kECDHr) { > ssl/ssl_lib.c- /* key usage, if present, must allow key = agreement */ > ssl/ssl_lib.c: if (ku_reject(x, X509v3_KU_KEY_AGREEMENT)) { > ssl/ssl_lib.c- = SSLerr(SSL_F_SSL_CHECK_SRVR_ECC_CERT_AND_ALG, > ssl/ssl_lib.c- = SSL_R_ECC_CERT_NOT_FOR_KEY_AGREEMENT); > ssl/ssl_lib.c- return 0; > -- > ssl/ssl_lib.c- } > ssl/ssl_lib.c- if (alg_a & SSL_aECDSA) { > ssl/ssl_lib.c- /* key usage, if present, must allow signing = */ > ssl/ssl_lib.c: if (ku_reject(x, = X509v3_KU_DIGITAL_SIGNATURE)) { > ssl/ssl_lib.c- = SSLerr(SSL_F_SSL_CHECK_SRVR_ECC_CERT_AND_ALG, > ssl/ssl_lib.c- SSL_R_ECC_CERT_NOT_FOR_SIGNING); > ssl/ssl_lib.c- return 0; >=20 > -- > Viktor. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_29DD6A1E-1105-48A2-8AD5-A771E347A4ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Suppose keyUsage is respected.  Who will knowingly shoot = themselves
in the foot and restrict their RSA certificate = to just DHE or just
RSA key transport?  This looks = like an impractical counter-measure.

I = guess we have to trade-off between different levels of =E2=80=9Cshooting = oneself in the foot=E2=80=9D.
For a company that has a bunch = of certificates, one for each domain, separate ECDSA and RSA = certificates etc. 
spending a few more dollars on = different certs for RSA encryption does not seem like a = lot.

In any case, the main issue is = whether we can get recipients to enforce key usage, not = senders.
If a cert explicitly enables key exchange, = encryption, and signature, it can be used for all of = these.
However, if the cert restricts itself to digital = signature, then the client should not use it for RSA = encryption.
That way, the server gets to choose whether it = wants protection from cross-protocol attacks or not,
and the = client will enforce its wishes correctly.

Regarding ECDSA->ECDH cross-protocol attacks, = the code that you pointed out in OpenSSL indeed
allows the = server to ensure it does not use a sign-only cert for ECDH, but other = libraries do not make this distinction.
Moreover, as far as I = know, OpenSSL clients do not enforce this key usage restriction (See = crypto/x509/x509type.c for the certificate usage = rules.)
Neither, for that matter do other TLS clients like NSS = etc. This allows attacks like the ECDH downgrade
in [1] and = can probably make the ECDSA key recovery attack in [2] quite a bit = worse.

=46rom the viewpoint of = provable security, I=E2=80=99d be suspicious of any TLS modes that allow = the same 
long-term keys to be used in multiple different = ways. For RSA/EC, there are known attacks. But even = otherwise,
their use requires a strong joint security = assumption that we don=E2=80=99t really know how to = justify.

-K.






And by the way key usage is enforced by OpenSSL for EC.

   $ git grep -C3 X509v3_KU_ = ssl
   ssl/ssl_lib.c- =        X509_check_purpose(x, -1, = 0);
   ssl/ssl_lib.c-# ifndef = OPENSSL_NO_ECDH
   ssl/ssl_lib.c- =        ecdh_ok =3D (x->ex_flags = & EXFLAG_KUSAGE) ?
   ssl/ssl_lib.c: =            (x->e= x_kusage & X509v3_KU_KEY_AGREEMENT) : 1;
=    ssl/ssl_lib.c-# endif
=    ssl/ssl_lib.c- =        ecdsa_ok =3D (x->ex_flags = & EXFLAG_KUSAGE) ?
   ssl/ssl_lib.c: =            (x->e= x_kusage & X509v3_KU_DIGITAL_SIGNATURE) : 1;
=    ssl/ssl_lib.c- =        if (!(cpk->valid_flags = & CERT_PKEY_SIGN))
   ssl/ssl_lib.c- =            ecdsa_ok= =3D 0;
   ssl/ssl_lib.c- =        ecc_pkey =3D = X509_get_pubkey(x);
   --
=    ssl/ssl_lib.c-    }
=    ssl/ssl_lib.c-    if (alg_k & = SSL_kECDHe || alg_k & SSL_kECDHr) {
=    ssl/ssl_lib.c- =        /* key usage, if present, must = allow key agreement */
   ssl/ssl_lib.c: =        if (ku_reject(x, = X509v3_KU_KEY_AGREEMENT)) {
=    ssl/ssl_lib.c- =            SSLerr(S= SL_F_SSL_CHECK_SRVR_ECC_CERT_AND_ALG,
=    ssl/ssl_lib.c- =             &n= bsp;     SSL_R_ECC_CERT_NOT_FOR_KEY_AGREEMENT);    ssl/ssl_lib.c- =            return = 0;
   --
=    ssl/ssl_lib.c-    }
=    ssl/ssl_lib.c-    if (alg_a & = SSL_aECDSA) {
   ssl/ssl_lib.c- =        /* key usage, if present, must = allow signing */
   ssl/ssl_lib.c: =        if (ku_reject(x, = X509v3_KU_DIGITAL_SIGNATURE)) {
=    ssl/ssl_lib.c- =            SSLerr(S= SL_F_SSL_CHECK_SRVR_ECC_CERT_AND_ALG,
=    ssl/ssl_lib.c- =             &n= bsp;     SSL_R_ECC_CERT_NOT_FOR_SIGNING);
   ssl/ssl_lib.c- =            return = 0;

--
= Viktor.

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

= --Apple-Mail=_29DD6A1E-1105-48A2-8AD5-A771E347A4ED-- --Apple-Mail=_4AC37C81-D2F1-4056-A064-FFCA0CDD008B 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 iQEcBAEBCgAGBQJWYVw9AAoJEB/WSo9veuUKV1gIAIuAhmCvt5GD4NtIaODkfw4l hD7x6tP9nGXWScbG8I/Ks9MgKq3UDwSotRJ//FjclvTiZESMwYnxQ9A6Il1ty9UV JUkn+/lFQBlx0582NlHu/V6S8A5jgxS5dJVu1nxkBg9BOF63+8J1PeHYeCydU+vt j+jpkRW8afvKcwZUpjtsafq2gRvjueMPceREwxoHoEg7lMji9Kgrj5K5optjTqA4 UmFEEhnwvH/UnYcYlyTIlJ4gJwBSnlyxixQ0sNgIbGtQB+7pBTVEdJWGDC7bg9U+ +q4DmIcQxu7YERkFywpzR+JFRVCtfVVnO+r+0rU0TVeQdlclvJJRxHDMa6DfoOY= =Kfb8 -----END PGP SIGNATURE----- --Apple-Mail=_4AC37C81-D2F1-4056-A064-FFCA0CDD008B-- From nobody Fri Dec 4 02:17:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926E81B2F6C for ; Fri, 4 Dec 2015 02:17:28 -0800 (PST) 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 aJ2kRJrANldV for ; Fri, 4 Dec 2015 02:17:26 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B691B2F6F for ; Fri, 4 Dec 2015 02:17:26 -0800 (PST) Received: by wmww144 with SMTP id w144so55668181wmw.1 for ; Fri, 04 Dec 2015 02:17:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=YqoOOmksrhrI4TXUXnc0PMi6CSuVti1UupZd1ZUDiXg=; b=lbMLBF816Zzky4G/eSlssrBiCG1QcGoJBR5g9f+VR22x/Y/3Y/XLr8Y7rL/Gk9Lc6X 3FdmjN2J8SZn1MVtvbABfEQH8KhU8xK/+m6X0B0xLWktAYUGIZ1GRNLT4Ima5VOkFlB9 c/FukdtM8QNyKRSzKWNrPlMd5m4J9YFBdYau+skL0p2tDQTmNzohSuGovfIDhq/maLcr u31D3omUJ+9bOjyo8MurtkmVTtip2SWUmCW6oZItWaF0rb/XK+D0oQf43KbIkNkPokPy uzFgFtQMNAv4FAn4tjLM38dhb7Z/a65OBFZjrAt9FjELPu9A9SWUKT1nTiIOKsjIUjN+ mqvA== X-Received: by 10.28.60.84 with SMTP id j81mr3894332wma.15.1449224244755; Fri, 04 Dec 2015 02:17:24 -0800 (PST) Received: from icsil1noteb193.epfl.ch (icsil1noteb193.epfl.ch. [128.178.151.41]) by smtp.gmail.com with ESMTPSA id a63sm2838551wmc.5.2015.12.04.02.17.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 04 Dec 2015 02:17:22 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: multipart/signed; boundary="Apple-Mail=_31B931E6-A4C6-40A1-A9D2-BB7F5C8DFF29"; protocol="application/pkcs7-signature"; micalg=sha1 From: Bryan Ford X-Priority: 3 In-Reply-To: <7F6CAD8F92F54AD5A4F6B14D5F471740@buildpc> Date: Fri, 4 Dec 2015 11:17:21 +0100 Message-Id: <071D813D-E2DD-48B6-8A53-52DC919F7401@gmail.com> References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> <565E1517.3060209@gmail.com> <9BDDC23D-1039-4C75-BF32-57330317BCAB@gmail.com> <7F6CAD8F92F54AD5A4F6B14D5F471740@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2015 10:17:28 -0000 --Apple-Mail=_31B931E6-A4C6-40A1-A9D2-BB7F5C8DFF29 Content-Type: multipart/alternative; boundary="Apple-Mail=_B805383B-C928-4BD7-BB7B-C72E186844BF" --Apple-Mail=_B805383B-C928-4BD7-BB7B-C72E186844BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 04 Dec 2015, at 07:56, Valery Smyslov wrote: > Hi Bryan, > =20 > I guess Dmitry is talking about the trick when each datagram is = encrypted with its own key,=20 > derived from the "master" session key using some unique public = parameter of the datagram, > like its sequence_number. This trick makes attacks on encryption key = almost useless. > It is not specifically bound to GOST cipher, however it is sometimes = used with this cipher=20 > to deal with its short (by current standards) block size. See for = example the (now expired) draft=20 > = https://www.ietf.org/archive/id/draft-fedchenko-ipsecme-cpesp-gost-04.txt = > (it is about ESP, but the general principles are the same for DTLS). Ah, I see - thanks for the clarification. > As far as I understand your proposal makes impossible to use this = trick,=20 > if we consider packets loss and reordering. Actually, if I=E2=80=99m understanding correctly how you=E2=80=99re = doing this per-datagram rekeying, I think it still should be compatible = with the hash-table-based approach I proposed. Assuming you=E2=80=99re = using some key derivation function that takes a master key and sequence = number as input and produces a per-datagram key, the receiver just needs = to pre-compute the per-datagram keys for the sequence numbers within the = current window, and encrypt the sequence numbers with those respective = per-datagram keys, in order to populate its hash table. I don=E2=80=99t = think anything breaks at least. Cheers Bryan --Apple-Mail=_B805383B-C928-4BD7-BB7B-C72E186844BF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On 04 Dec 2015, at 07:56, Valery Smyslov <svanru@gmail.com> = wrote:
Hi Bryan,
 
I guess Dmitry is talking about = the trick when each datagram is encrypted with its own key, 
derived from the "master" session = key using some unique public parameter of the datagram,
like its sequence_number. This = trick makes attacks on encryption key almost = useless.
It is not = specifically bound to GOST cipher, however it is sometimes used with this cipher 
to deal with its short (by = current standards) block size. See for example the (now expired) draft 
(it is about ESP, but the general principles are = the same for DTLS).

Ah, I see - thanks for the = clarification.

As far as I = understand your proposal makes impossible to use this trick, 
if we consider packets loss and = reordering.

Actually, if I=E2=80=99m understanding correctly = how you=E2=80=99re doing this per-datagram rekeying, I think it still = should be compatible with the hash-table-based approach I proposed. =  Assuming you=E2=80=99re using some key derivation function that = takes a master key and sequence number as input and produces a = per-datagram key, the receiver just needs to pre-compute the = per-datagram keys for the sequence numbers within the current window, = and encrypt the sequence numbers with those respective per-datagram = keys, in order to populate its hash table.  I don=E2=80=99t think = anything breaks at least.

Cheers
Bryan

= --Apple-Mail=_B805383B-C928-4BD7-BB7B-C72E186844BF-- --Apple-Mail=_31B931E6-A4C6-40A1-A9D2-BB7F5C8DFF29 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTEyMDQxMDE3MjJaMCMGCSqGSIb3DQEJBDEWBBQsoSDVbHqhLrj9v3Z4/mYudFd5TTCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAp6eLCoe5aGAAWRJ9KaqzR/gLA4FqAYVkKSr+TgUb/bE89XY+JYuE/DKXK8rgH8t0 K0orBIjzdg58NXGetflwZbj7+l/7GfTBVOSZ26tX9mhisG8HkmBVye818CdFnR3C4q4DVEgz5cdk ymDzcLDey4CGWETg1icBQR5d0MxnUGtKskfGM6SxspWI3vLNTLxGjC7KkuAU2Faonlk14WUvb0zR G1tXdLxdVVj6Jl2pIdM84S3CI/VKcIi9lueHqORevyhUcvrjwQaHwGE1QjGlPfom809oUj2ejHm5 nQO+7pPnkpNgOy0RXRG3uoHGg0zmHMjEzN/ilGhZpkfa+uFM0gAAAAAAAA== --Apple-Mail=_31B931E6-A4C6-40A1-A9D2-BB7F5C8DFF29-- From nobody Fri Dec 4 04:52:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C40E1B3116 for ; Fri, 4 Dec 2015 04:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 DgipGBYvbcse for ; Fri, 4 Dec 2015 04:52:20 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 756031B3114 for ; Fri, 4 Dec 2015 04:52:19 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id DE7C8BE94DC92; Fri, 4 Dec 2015 12:52:15 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id tB4CqHQH004879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Dec 2015 13:52:17 +0100 Received: from FR712WXCHMBA13.zeu.alcatel-lucent.com ([169.254.5.200]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 4 Dec 2015 13:52:17 +0100 From: "GUBALLA, JENS (JENS)" To: Bryan A Ford , Fabrice Gautier Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all? Thread-Index: AQHRLbAt05dFICSaPkazPz5t63/sbZ66xIBg Date: Fri, 4 Dec 2015 12:52:17 +0000 Message-ID: <547EE95EB794FD4DB8062F7A4C86D0BC4A3A04DF@FR712WXCHMBA13.zeu.alcatel-lucent.com> References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <547EE95EB794FD4DB8062F7A4C86D0BC4A39F163@FR712WXCHMBA13.zeu.alcatel-lucent.com> <5660109C.7070803@gmail.com> In-Reply-To: <5660109C.7070803@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0018_01D12E9A.FBDB7580" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2015 12:52:23 -0000 ------=_NextPart_000_0018_01D12E9A.FBDB7580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Brian, > -----Original Message----- > From: Bryan A Ford [mailto:brynosaurus@gmail.com] > Sent: Donnerstag, 3. Dezember 2015 10:51 > To: GUBALLA, JENS (JENS); Fabrice Gautier > Cc: tls@ietf.org > Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 > after all? > > Hi Jens, > > On 12/2/15 11:47 AM, GUBALLA, JENS (JENS) wrote: > >> Fortunately the solution is fairly simple: the receiver simply pre- > >> computes and keeps in a small hash table the encrypted sequence > numbers > >> of all packets with sequence numbers between H-W and H+W, where H is > >> the highest sequence number correctly received so far (the horizon) > and > >> W is the anti-replay window size as specified in 4.1.2.5 of RFC > 4347, > >> which typically should be 32 or 64 according to the RFC. The > receiver > >> can precompute all these encryptions because in my proposal TLS > headers > >> are encrypted with a stream cipher (or the AEAD operating as a > stream > >> cipher), so it's just a matter of producing the correct cipherstream > >> bytes and XORing them with the uint48 sequence number. > >> > >> Whenever the receiver gets a datagram, it looks up the encrypted > >> sequence number in the hash table, drops it on the floor if it's not > >> present, and if it's present the receiver gets the decrypted > sequence > >> number from the hash table and uses that in the AEAD decryption and > >> integrity-check. In the low-probability event of a hash-table > >> collision (i.e., two uint48 sequence numbers encrypting to the same > 48- > >> bit ciphertext in a single 129-datagram window), the receiver can > >> trial-decrypt with both (or all) sequence numbers in that colliding > >> hash table entry. Or the receiver can keep it even simpler and just > >> drop all but one colliding entry, introducing a pretty low > probability > >> of introducing occasional "false packet drops." > >> > >> The hash table is pretty trivial to maintain efficiently as well: > e.g., > >> whenever the horizon H moves forward by delta D, remove the first D > >> entries from the current window and precompute another D encrypted > >> sequence numbers (where D will most often be 1). In the simple > design > >> that doesn't bother dealing with hash table collisions (e.g., that > >> allows each hash table entry to contain only one value), perhaps > don't > >> even bother clearing/removing old entries; just gradually overwrite > >> them with new ones as H moves forward. > > > > [JG] In case there is a packet loss of at least W subsequent DTLS > records: > > How can the receiver then ever adjust its hash table? Wouldn't that > mean > > that no records at all would be accepted anymore? > > Excellent question - I had intended to discuss that in my original post > but in the end forgot to include it. > > Indeed, with this approach as it stands, if every packet within a full > window of W consecutive packets fails to reach the receiver, then the > receiver has no way to resynchronize and the connection will simply > fail. In congestion-controlled protocols like TCP (or DCCP) that do > exponential backoff when they detect many consecutive losses, the > protocol may be more likely simply to hard-timeout than to reach the > W-packet resynchronization limit. But admittedly many UDP-based > protocols aren't (or are rather weakly) congestion-controlled, so this > may be more of a problem for them. It's probably the case that the > "forward-looking window" should be allowed to have a different value > from the "backward-looking window", and perhaps the "forward-looking > window" should depend on RTT (e.g., measured maximum packets-in- > flight). > > However, one way to eliminate this risk of permanent desynchronization, > at the cost of a bit more complexity in the receiver implementation > (though this needn't affect the protocol spec at all) is for the > receiver's "forward-looking window" to consist not of W consecutive > sequence numbers but a sparse set of sequence numbers at > exponentially-increasing distances. For example, if H is the current > highest sequence number, include in the forward-looking cache the > encrypted sequence numbers of the sequence number of the next multiple > of 2^1 beyond H, the next multiple of 2^2, etc., for as many multiples > of powers-of-two to get sufficiently far out in the sequence number > space where we're convinced there's no realistic chance of a run of > total or near-total packet loss unless it really means the connection > is > dead anyway. :) [JG] That would mean legitimate records would be dropped until an entry in the hash would match. Thus this proposal would potentially degrade the service, right? Basically I fail to see how a stream cipher can be operated reliable on top of an unreliable transport protocol. Best regards, Jens > > Again, these are all considerations that need not affect the protocol > but could be tuned by implementations (perhaps with some > recommendations > in the protocol spec). > > But regardless, all of this is just to make the case that header > encryption is in principle just as feasible in DTLS as in TLS, and > using > fairly similar techniques; right now I think we should keep the main > focus on whether to do it (at least) in TLS, for which is seems pretty > easy to do it in at least two different ways I've proposed. > > B ------=_NextPart_000_0018_01D12E9A.FBDB7580 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/DCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYjCCBkqgAwIBAgIKE1mSVAAAAADt+zANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDI0MDYyNDM5WhcNMTcwNDIz MDYyNDM5WjBCMRAwDgYDVQQDEwdsdnBzYWFlMS4wLAYJKoZIhvcNAQkBFh9qZW5zLmd1YmFsbGFA YWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuZZTGrNK 9hSyYEI9w2lnABbWQBeU1DyJ9jX33JSOfgMGYaQ0ZZZFRwX5vDIgj499CxaWmpImbQTxdYa/vxpS U7SfqtYF7B2AB2irUYdCu/GGjTqHaXmPyyktPaiEOgR7AOz8oXxUdaECsKmTBANOpkE1J6yA3KPJ Yxde3h5bTqnjxvJB5IJhr9rIvcf5V3v6ZyW0MHOkDXn20xjEDJVMVdhhjlnwM4WmUiA/SNq7IiQ8 elmivF5NuEK9mwZEXqkR6aXHVcgPc1fuMxwsxJbdfdmMyIDV62kSTVlb/iXNJDByQJ/GRnuYHCFA qIld1HgdJCpECl+ohveGLG46CvD6iwIDAQABo4IEFDCCBBAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIhb3FWYPjsTmHpYEqhr/DQoWUmBmBC/nmTIT9tVoCAWQCAQUwHwYDVR0lBBgwFgYKKwYB BAGCNwoDBAYIKwYBBQUHAwQwCwYDVR0PBAQDAgWgMCkGCSsGAQQBgjcVCgQcMBowDAYKKwYBBAGC NwoDBDAKBggrBgEFBQcDBDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG 9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFPUv0vuw2MQvQ81rxR/PDOlK po4KMB8GA1UdIwQYMBaAFNnsa72WWCL32KZ3zf5Nge+6l70SMIIBXQYDVR0fBIIBVDCCAVAwggFM oIIBSKCCAUSGgdlsZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQlMjBJbnRlcm5hbCUyMFN1YiUy MENBLENOPXVzbmF2c3BraTAzcCxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1sdWFkLERDPWx1Y2VudCxEQz1jb20/Y2VydGlm aWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50 hixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNybIY4aHR0cDovL3Nl cnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmwwggFhBggrBgEF BQcBAQSCAVMwggFPMIHMBggrBgEFBQcwAoaBv2xkYXA6Ly8vQ049QWxjYXRlbCUyMEx1Y2VudCUy MEludGVybmFsJTIwU3ViJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NBQ2Vy dGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDgGCCsGAQUF BzAChixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNydDBEBggrBgEF BQcwAoY4aHR0cDovL3NlcnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJD QS5jcnQwKgYDVR0RBCMwIYEfamVucy5ndWJhbGxhQGFsY2F0ZWwtbHVjZW50LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAXRHvujXQqqJMH1wCrG+0UrRv0v7CpjhIyuLwJ5XDhTj9JcKsYLpWREi/zXhN Sy6TC61uUKLrAuX0uXAXW0zsBYgPDFkq481gTgdxG/brcg8lXF8Xm787ixPR8Mp8j80ZHZ5OnA1k +Xuw/QPsE4wp8RZrjqvoJQpSXtXPdX3+XBE0VsANBYszCWfrR0ByI4hZ9Saoc26umYnOY8sU0UZ/ 1XnEcRfUmVWRxTydYAFdTtOHRjBn3V7TZnfeGYpKSxrqdh6nTqk0FR832p8Z8RyNjEv3qdaX9BK7 jsjQgGNH0gxWPf+wARDdk5abnalyChTjv8B70KeLOYbsrF0greiw3TGCBCkwggQlAgEBMIGUMIGF MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPy LGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVj ZW50IEludGVybmFsIFN1YiBDQQIKE1mSVAAAAADt+zAJBgUrDgMCGgUAoIICaTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMDQxMjUyMTVaMCMGCSqGSIb3DQEJ BDEWBBQ7oP1frRuiuo1lQ3VhM4HQy0vRgTCBpQYJKwYBBAGCNxAEMYGXMIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKE1mSVAAAAADt+zCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYUxEzARBgoJkiaJ k/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAy MRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJu YWwgU3ViIENBAgoTWZJUAAAAAO37MIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJYIZIAWUDBAEqMAsG CWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzAL BglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAJk5 9sT3zsugoVshc+y6gsZbq7IneVtn+UMtkbfwc7Kv5A7Z7XmnQ3/JfBL7WgPbRF4fhZUXytYCIXcg 9TVuFvZLuAsOgJVlwSi15bJFJaWyKdeBUKAH4WZD7Fw87ZFRpjs4njAn8rPreck5q/7tkmq4iTAg uEg+9qaRXzPOJHk+7787/Im0EfEnGEhdCLdV6/vqIYBJtzMgdbuKhdqDwJ8GH9U5UQvkttLz7CzM O33ihDSuzqpRe+3ZWKH+Nb/VU70Hrahp3xKphSeq71OWYR26lEYQtS39pQw6ZWRcD4YdJET6Pkok segr58TwYKvPdg944E+VNXVGmmyjhi96vWcAAAAAAAA= ------=_NextPart_000_0018_01D12E9A.FBDB7580-- From nobody Fri Dec 4 04:57:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CF31B3125 for ; Fri, 4 Dec 2015 04:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.171 X-Spam-Level: X-Spam-Status: No, score=0.171 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, RCVD_IN_SORBS_WEB=0.77, 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 7yM0av5Yk-2U for ; Fri, 4 Dec 2015 04:57:31 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 849451B3121 for ; Fri, 4 Dec 2015 04:57:31 -0800 (PST) Received: by lffu14 with SMTP id u14so111408520lff.1 for ; Fri, 04 Dec 2015 04:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type; bh=SI7UeqPrzY1XQ6qQKW8PFvp4sOkM+lfGrdTIfpu1Qgc=; b=LMeCgJdYb6/wm8hig3I48+3pTg3bx53XAgB1NioaQNTaO6SUkigCT14QtiMh55CpzI IB84sCyjGGS9U7mrvHlkCciKs3vo+E3BIO/Rce10ZmS2frWGMtH0SeBkfBUoFj079cUE 1WsEUKDZAQhkF2CroExDlTaScUXDeYcO/otOa0RCOfPiImjOfm3d5qAOpG7IJ+XgvwsZ KmChCAjo3hnSzuFbDB2l8o5NwnY/Xy52WCTODJgV0fbyJWHd2D6t7GCH05cUNaITucCD lTGopmayoltfU0dynGvt4WqIgkJP+r5EozOXqTVGjFpVfVJwfZRSR0uTJXlNb3J9eQ5K 8gzw== X-Received: by 10.25.38.2 with SMTP id m2mr8163339lfm.113.1449233849674; Fri, 04 Dec 2015 04:57:29 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id j189sm2289361lfg.46.2015.12.04.04.57.28 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Dec 2015 04:57:28 -0800 (PST) Message-ID: <22CF6E6F4D484DE5B3031B0EAD612F52@buildpc> From: "Valery Smyslov" To: "Bryan Ford" References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> <565E1517.3060209@gmail.com> <9BDDC23D-1039-4C75-BF32-57330317BCAB@gmail.com> <7F6CAD8F92F54AD5A4F6B14D5F471740@buildpc> <071D813D-E2DD-48B6-8A53-52DC919F7401@gmail.com> Date: Fri, 4 Dec 2015 15:57:27 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0BF2_01D12EAC.7963A0C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2015 12:57:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0BF2_01D12EAC.7963A0C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As far as I understand your proposal makes impossible to use this = trick,=20 if we consider packets loss and reordering. Actually, if I=E2=80=99m understanding correctly how you=E2=80=99re = doing this per-datagram rekeying, I think it still should be compatible = with the hash-table-based approach I proposed. Assuming you=E2=80=99re = using some key derivation function that takes a master key and sequence = number as input and produces a per-datagram key, the receiver just needs = to pre-compute the per-datagram keys for the sequence numbers within the = current window, and encrypt the sequence numbers with those respective = per-datagram keys, in order to populate its hash table. I don=E2=80=99t = think anything breaks at least. I would say that the hash-table-based approach would work in theory. In practice it either implies too much burden on the receiver or would = fail in some situations. Consider, for example, situation when the sender=20 skips large amount of sequence numbers (say 2^32) for some reason. It would be difficult for receiver to build such a hash table. Regards, Valery Smyslov. ------=_NextPart_000_0BF2_01D12EAC.7963A0C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
 
As far as I understand your proposal makes impossible to = use this=20 trick, 
if we consider packets loss=20 and reordering.

Actually, if I=E2=80=99m understanding correctly how = you=E2=80=99re doing this=20 per-datagram rekeying, I think it still should be compatible with the=20 hash-table-based approach I proposed.  Assuming you=E2=80=99re = using some key=20 derivation function that takes a master key and sequence number as = input and=20 produces a per-datagram key, the receiver just needs to pre-compute = the=20 per-datagram keys for the sequence numbers within the current window, = and=20 encrypt the sequence numbers with those respective per-datagram keys, = in order=20 to populate its hash table.  I don=E2=80=99t think anything = breaks at=20 least.
I would say that the hash-table-based = approach=20 would work in theory.
In practice it either implies too much = burden on the=20 receiver or would fail
in some situations. Consider, for example, = situation=20 when the sender
skips large amount of sequence numbers = (say=20 2^32) for some reason.
It would be difficult for receiver to = build such a=20 hash table.
 
Regards,
Valery Smyslov.
------=_NextPart_000_0BF2_01D12EAC.7963A0C0-- From nobody Fri Dec 4 05:34:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18F11B3188 for ; Fri, 4 Dec 2015 05:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 GMfMnrG55U6T for ; Fri, 4 Dec 2015 05:34:22 -0800 (PST) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id D31CD1B3187 for ; Fri, 4 Dec 2015 05:34:21 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id tB4DXgLJ017828; Fri, 4 Dec 2015 08:34:05 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Valery Smyslov , Bryan Ford Thread-Topic: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) Thread-Index: AdEumG8ZFHboNUopsEeqgRivNm8DvQ== Date: Fri, 4 Dec 2015 13:34:00 +0000 Message-ID: <20151204133409.17788988.58221.38550@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============1084548272==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2015-12-04_06:2015-12-03,2015-12-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-1511060000 definitions=main-1512040222 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2015 13:34:28 -0000 --===============1084548272== Content-Type: multipart/alternative; boundary="===============0201074781==" MIME-Version: 1.0 --===============0201074781== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SSdtIHdpdGggVmFsZXJ5IGhlcmUuIElNSE8gdGhlIHByb3Bvc2VkIG1lY2hhbmlzbSBtYWtlcyBs aXR0bGUgc2Vuc2UgYmVjYXVzZSAocG9saXRpY3Mgbm90d2l0aHN0YW5kaW5nKSBpdCBvZmZlcnMg bGl0dGxlIGdhaW4gaW4gcmV0dXJuIG9mIGEgc2lnbmlmaWNhbnQgKHBvc3NpYmx5IHVuYWNjZXB0 YWJsZSkgYnVyZGVuIHRvIGltcG9ydGFudCB1c2UgY2FzZXMuwqAKClBlcnNvbmFsbHkgSSdtIGZp cm1seSBhZ2FpbnN0IGl0LsKgCgo8cHJvcGVyIGRpc2NsYWltZXJzPgpTZW50wqBmcm9twqBtecKg QmxhY2tCZXJyecKgMTDCoHNtYXJ0cGhvbmXCoG9uwqB0aGUgVmVyaXpvbsKgV2lyZWxlc3PCoDRH wqBMVEXCoG5ldHdvcmsuCkZyb206IFZhbGVyeSBTbXlzbG92ClNlbnQ6IEZyaWRheSwgRGVjZW1i ZXIgNCwgMjAxNSAwNzo1NwpUbzogQnJ5YW4gRm9yZApDYzogdGxzQGlldGYub3JnClN1YmplY3Q6 IFJlOiBbVExTXSBGdWxseSBlbmNyeXB0ZWQgYW5kIGF1dGhlbnRpY2F0ZWQgaGVhZGVycyAod2Fz IFJlOiBFbmNyeXB0aW5nIHJlY29yZCBoZWFkZXJzOiBwcmFjdGljYWwgZm9yIFRMUyAxLjMgYWZ0 ZXIgYWxsPykKCsKgCkFzIGZhciBhcyBJIHVuZGVyc3RhbmQgeW91ciBwcm9wb3NhbCBtYWtlcyBp bXBvc3NpYmxlIHRvIHVzZSB0aGlzIHRyaWNrLMKgCmlmIHdlIGNvbnNpZGVywqBwYWNrZXRzIGxv c3MgYW5kIHJlb3JkZXJpbmcuCgpBY3R1YWxseSwgaWYgSeKAmW0gdW5kZXJzdGFuZGluZyBjb3Jy ZWN0bHkgaG93IHlvdeKAmXJlIGRvaW5nIHRoaXMgcGVyLWRhdGFncmFtIHJla2V5aW5nLCBJIHRo aW5rIGl0IHN0aWxsIHNob3VsZCBiZSBjb21wYXRpYmxlIHdpdGggdGhlIGhhc2gtdGFibGUtYmFz ZWQgYXBwcm9hY2ggSSBwcm9wb3NlZC4gwqBBc3N1bWluZyB5b3XigJlyZSB1c2luZyBzb21lIGtl eSBkZXJpdmF0aW9uIGZ1bmN0aW9uIHRoYXQgdGFrZXMgYSBtYXN0ZXIga2V5IGFuZCBzZXF1ZW5j ZSBudW1iZXIgYXMgaW5wdXQgYW5kIHByb2R1Y2VzIGEgcGVyLWRhdGFncmFtIGtleSwgdGhlIHJl Y2VpdmVyIGp1c3QgbmVlZHMgdG8gcHJlLWNvbXB1dGUgdGhlIHBlci1kYXRhZ3JhbSBrZXlzIGZv ciB0aGUgc2VxdWVuY2UgbnVtYmVycyB3aXRoaW4gdGhlIGN1cnJlbnQgd2luZG93LCBhbmQgZW5j cnlwdCB0aGUgc2VxdWVuY2UgbnVtYmVycyB3aXRoIHRob3NlIHJlc3BlY3RpdmUgcGVyLWRhdGFn cmFtIGtleXMsIGluIG9yZGVyIHRvIHBvcHVsYXRlIGl0cyBoYXNoIHRhYmxlLiDCoEkgZG9u4oCZ dCB0aGluayBhbnl0aGluZyBicmVha3MgYXQgbGVhc3QuCkkgd291bGQgc2F5IHRoYXTCoHRoZSBo YXNoLXRhYmxlLWJhc2VkIGFwcHJvYWNoIHdvdWxkIHdvcmvCoGluIHRoZW9yeS4KSW4gcHJhY3Rp Y2UgaXQgZWl0aGVyIGltcGxpZXMgdG9vIG11Y2ggYnVyZGVuIG9uIHRoZSByZWNlaXZlciBvciB3 b3VsZCBmYWlsCmluIHNvbWUgc2l0dWF0aW9ucy4gQ29uc2lkZXIsIGZvciBleGFtcGxlLCBzaXR1 YXRpb24gd2hlbiB0aGUgc2VuZGVyCnNraXBzIGxhcmdlIGFtb3VudCBvZiBzZXF1ZW5jZSBudW1i ZXJzIChzYXkgMl4zMinCoGZvciBzb21lIHJlYXNvbi4KSXQgd291bGQgYmUgZGlmZmljdWx0IGZv ciByZWNlaXZlciB0byBidWlsZCBzdWNoIGEgaGFzaCB0YWJsZS4KwqAKUmVnYXJkcywKVmFsZXJ5 IFNteXNsb3YuCgo= --===============0201074781== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable =
I'm with Valery here. IMHO the proposed mechanism makes little sense b= ecause (politics notwithstanding) it offers little gain in return of a sign= ificant (possibly unacceptable) burden to important use cases. 
<= div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate = Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-= color: rgb(255, 255, 255);">
Personal= ly I'm firmly against it. 
= =

<proper disclaimers>
= =
=
Sent from my BlackBerry 10 smartphone on&nbs= p;the Verizon Wireless 4G LTE network.
= = =
=
= From: Valery Smyslov
Sent: Friday, December 4, 2015 07= :57
To: Bryan Ford
Cc: tls@ietf.org
=
Subject: Re: [TLS] Fully encrypted and authenticated headers (w= as Re: Encrypting record headers: practical for TLS 1.3 after all?)
 
As far as I understand your proposal makes impossible to u= se this trick, 
if we consider = packets loss and reordering.

Actually, if I=E2=80=99m understanding correctly how you=E2=80=99re do= ing this per-datagram rekeying, I think it still should be compatible with = the hash-table-based approach I proposed.  Assuming you=E2=80=99re usi= ng some key derivation function that takes a master key and sequence number as input and produces a per-datagram key, the receiver just needs t= o pre-compute the per-datagram keys for the sequence numbers within the cur= rent window, and encrypt the sequence numbers with those respective per-dat= agram keys, in order to populate its hash table.  I don=E2=80=99t think anything breaks at least.
I would say that the hash-table-base= d approach would work in theory.
In practice it either implies too much bu= rden on the receiver or would fail
in some situations. Consider, for example= , situation when the sender
skips large amount of sequence numbers (s= ay 2^32) for some reason.
It would be difficult for receiver to bui= ld such a hash table.
 
Regards,
Valery Smyslov.

--===============0201074781==-- --===============1084548272== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKTM8n7QAAAABB0TANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE1MDYwNTE4MTY0NFoXDTE2MDYwNDE4MTY0NFowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDQ 0ZYk84x0NrbLSMf9w+9rvO8Z3d5dfpynEt9it4HkQ3Fht5wpD1DOICbdPmcuoNGv73LUI6oRn7XT CnAFOeW9dGZetOUBIL44l0BoMYlUOvqOhtXUIoxm6PNbnDsYW3HpNuiskGO+jjH5CrvSFsZ//GHA dMGsQpRNBU7ZHCoOZF7+rv9RUh5pN5OgKumv9p24nWtGHNR1AHHDjB50Df9/1DVGhpe6aqf5DBhe f+1rf/dgAhjFSzrj3lTgNuczkZcB9Xs6fktq1jRCuwCdVTXQ/xgM5I3FHnVP73QEccOFR9qfdEVA 5IT7jo/7hMIvOBMWUJGOP7BpYXJd4VKj8CxLAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUr3pideNu 8mmOhHY8C2sJnlo/HVAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAKVaDwP2SaWtXtIINTrHpvDXC9dslWAv Tfg3TmHrQMtlKM6GQqkgIzF4WMZgM64RyUOqEnXrDcD7a3GPrcf8zDjRnsTiYaGkzhEUb/do5igL Al5x+FwAvhwvEuLJwHpAk0sfbxfX4lxY1S1YUngS+5PXGJbbFaNPAOefDG8jGgaM4TJ1weWlLT8F /MJudL6L6azCfOWQZhxpnT037XWGPeUfuqNnmwkwwlrCQB2QYgLQJtlUZQPqnb8Y2hd6OfhE7qvv /fcvX7i+Q4UKh3xGlMN2QHoX0Sk9sxxc4vgJnKk7MhaufGtOuNJLZlSfzCQRGd9Zprq9M+ROXuwN u72bKQkwggTqMIID0qADAgECAgpMzyftAAAAAEHRMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTUwNjA1MTgxNjQ0WhcNMTYwNjA0MTgxNjQ0WjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANDRliTzjHQ2tstIx/3D72u87xnd3l1+nKcS32K3geRDcWG3nCkPUM4gJt0+Zy6g0a/v ctQjqhGftdMKcAU55b10Zl605QEgvjiXQGgxiVQ6+o6G1dQijGbo81ucOxhbcek26KyQY76OMfkK u9IWxn/8YcB0waxClE0FTtkcKg5kXv6u/1FSHmk3k6Aq6a/2nbida0Yc1HUAccOMHnQN/3/UNUaG l7pqp/kMGF5/7Wt/92ACGMVLOuPeVOA25zORlwH1ezp+S2rWNEK7AJ1VNdD/GAzkjcUedU/vdARx w4VH2p90RUDkhPuOj/uEwi84ExZQkY4/sGlhcl3hUqPwLEsCAwEAAaOCAbIwggGuMB0GA1UdDgQW BBSvemJ1427yaY6EdjwLawmeWj8dUDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEApVoPA/ZJpa1e0gg1Osem 8NcL12yVYC9N+DdOYetAy2UozoZCqSAjMXhYxmAzrhHJQ6oSdesNwPtrcY+tx/zMONGexOJhoaTO ERRv92jmKAsCXnH4XAC+HC8S4snAekCTSx9vF9fiXFjVLVhSeBL7k9cYltsVo08A558MbyMaBozh MnXB5aUtPwX8wm50vovprMJ85ZBmHGmdPTftdYY95R+6o2ebCTDCWsJAHZBiAtAm2VRlA+qdvxja F3o5+ETuq+/99y9fuL5DhQqHfEaUw3ZAehfRKT2zHFzi+AmcqTsyFq58a0640ktmVJ/MJBEZ31mm ur0z5E5e7A27vZspCTCCBO0wggPVoAMCAQICCihwejIAAAAALQcwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNTAxMjMxNzQ5MjlaFw0xNjAxMjMxNzQ5MjlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxfkXLPYTTuYb5RNGHpbanlxlFtbt0VTBuP9moOidhYHLDicTmcv5vuxX mHwqN12Kzasev9yGZg0mJZ9yZ8cz4qJw3GytkyfcQDqFpa1MpAIYFJfjwjvGoQ1eWHNLZjM3+TFw a7Lm9J1MiXg5MTlGNiHefA9VFc814fSr43PmQnAURaFYgIJ+zM557ryvGOZuy6K9aC1ksTTVMqff IAuBKXRy5wPMj9Vqpja9MfmLLIyYBIiH2RasfBr79jqrR2hRh4e2OvljliGVCzGgHPSSRKvHLZ7P ZhiEZXX9iTBXDbGoUCQ4YFLKZj+nNVs/Tq1MbIMJxkOX3iKvXP+GGWBGfwIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFEdIXm5OIutOt2J6RBFV8kFMn0hTMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQA4puc4 02/4d3mv+ugzTOsEpotU4vRdn9vwK3tmu2vRPyD135Xod/ZVRu7k2p3hCTEh8w5bZAeZOg2DL/7d vJ7UJtoyyPWnTMHHA5SkkdriA7IgO46HYk8W6i/2kYvlguMm1loV7s0m5DHrGsreUACqbiiwK+53 sH2WlsfMz51lNZ1mQWyUe3CyoFE2hIkLvzZQliBSSAvckYc3vikeNbyGvu54kJ1ADY6GAgrt9mfM YMYSuJEK+bXlFVDQ6Ao9Nse/NRhX8ApJ8abFhJveTljNYmlyghifHIoqLpRM5LGVKyB3SJiEmkFV fl3Zm3Hdzh+svHzZdZmXV5/LMTSXPv4NMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgpMzyftAAAAAEHRMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTIwNDEzMzQwOFowLwYJKoZIhvcNAQkEMSIEICv9Idp0NERB MpYu3qYkpaMp3evU4OR9gTrtaakaAj0DMAsGCSqGSIb3DQEBCwSCAQB5kGIxhdn8aaQTVsaLYHVR 8Dd4AYPdd4O6IAhj7ExhE4PhCMPdEuvPcKhs+tavW8cDwzTMiJU8vtdCsrYkLyYYaqk6hC/aE279 KzEMwKzWp2qiCrUkzp1lkQ5QOiWDSCDin1r6PdJsaaQXOSvsyW7VBZQfGfb6Oxe4mRtjB9x/NVYu yVkLj3MVVFAgOnqVb3EhR7hmYf3pu5UzPpCDA2gMIVrr0jS/krbkj/4eYBfDpCNI09SM51FykkEw E9qlT5GYBKvCYYNHasn/Q90JuncYgUwNotdntQiy2jV0mTBbq/rPVoJsUDjU5h8WNifq7+cbv0ge 3iEYeRirJQ+p60C0AAAAAAAA --===============1084548272==-- From nobody Fri Dec 4 07:39:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21AF1A87E1 for ; Fri, 4 Dec 2015 07:39:20 -0800 (PST) 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] 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 wvYE6kfKfkqx for ; Fri, 4 Dec 2015 07:39:19 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC9FC1A87EF for ; Fri, 4 Dec 2015 07:39:13 -0800 (PST) Received: by igl9 with SMTP id 9so35274265igl.0 for ; Fri, 04 Dec 2015 07:39:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KPVmW4mfj80mrs8OpIXAPp0PdJLV3RtC/5HY3u6NLqU=; b=V+O8N9spU0DACx/1Qgev2tJb935Utnl4KLaCxlevfjBH/R6e1Eta1i/2HjsgNJgSkb SmNAML0GCirDnoeHLCssUG99b3EySjiaFHoeYjngNBmBdaozFnkD1mvdHcdkgj33APM4 af1TVxgKigRzfL8O4OW3t47bX7thkyhEiSaivLjM/tVMFhiUNFrw76jIUe+SSksw/e3z 0gZ70YCjy1RW+JKSmjKpl7bVQLsrCmafeben1c6zwsSiuAF+PTUjr44HeWzKfK7f5q5I RiHc3cjknKlWxS8yFw02pmK7ctdqrxm6v1RAa6uLAvc8/b/vRXUtK+ux9Zsl+U0NRQSK 0WLA== 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=KPVmW4mfj80mrs8OpIXAPp0PdJLV3RtC/5HY3u6NLqU=; b=V9eW0tQ2fl69CcKDMBwz17x8T4aFycUSO/LVdqQMrf9KSWG1pShJ/F9OowcsnHWK4j OcgQ6YQN0+4OUXLITJX2Lazewcw+sJ2TzHbIVBJi8ia9fTxPg/S2XVhxQOumSjytwtQJ oPgB3SU0uWGTBpeDuLt9FTriPbXbhWfvGSyHS8GK9HlYw/wg9GFLgMSyWieM6Gifo+D5 iJHbr682dUvkLEKWG/JVE8Bo2Xydb7vZrg4JCm9bxJ7FF5kJEyY2jmvzbWXROAcyPPJU zp7nn45jENzNJxXYbalqR7XftfLZyA9wCXuMYHR82LhKLEvetL6+7CMLPbjwB1Qm+e2h 67Jw== X-Gm-Message-State: ALoCoQk1jExiTnd28IRVihpaV2/gGAf6bnJuzti+5AW4b8DgQrD6qR3Mq2H4YGdwZRJ3b+/40VuD MIME-Version: 1.0 X-Received: by 10.50.155.73 with SMTP id vu9mr4815061igb.89.1449243553239; Fri, 04 Dec 2015 07:39:13 -0800 (PST) Received: by 10.79.70.71 with HTTP; Fri, 4 Dec 2015 07:39:13 -0800 (PST) X-Originating-IP: [5.9.36.66] In-Reply-To: References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> <9BFA68AB-9677-4BE7-8F5E-D1A66EF95BA5@gmail.com> Date: Fri, 4 Dec 2015 15:39:13 +0000 Message-ID: From: Jacob Appelbaum To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2015 15:39:21 -0000 On 12/2/15, Watson Ladd wrote: > On Wed, Dec 2, 2015 at 10:34 AM, Jacob Appelbaum >> >> I think that it eliminates all static distinguisher in the protocol >> for all data covered by the encryption. That is a fantastically >> wonderful benefit. > > What's a "static distinguisher"? Padding solves this problem as well, > but it also solves problems resulting from TCP segmentation down the > stack, which header encryption doesn't. What does header encryption > offer that padding does not? > Fixed parts of a protocol are often considered as static distinguishers - most are unavoidable unless you take the Scramblesuit design approach and have a keyexchanged out of band. Elligator is another useful design in this direction. In the case of TLS, we've seen a specific Oakley group used as the distinguisher that selected all related (TCP) flows for disruption. Changing that to a (well formed) randomly selected value allowed traffic to flow freely again. Other static values like a site specific plaintext name are used much more commonly. I could imagine for example that all records with a given length can be selected and dropped, for example. Common VoIP applications that use fixed lengths are thus even easier to censor with an exposed length field. With that value hidden and with *random* padding, I think the ease of selecting specific flows would be reduced and the cost would be much higher. No everyone needs padding but many people will want that value hidden without a useful way to do it unless the protocol supports it by default. All the best, Jacob From burdges@gnunet.org Fri Dec 4 08:21:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75F01A8982 for ; Fri, 4 Dec 2015 08:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-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 cmu87ZQcAZn7 for ; Fri, 4 Dec 2015 08:21:02 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2022E1A8981 for ; Fri, 4 Dec 2015 08:21:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.20,380,1444687200"; d="asc'?scan'208";a="190472285" Received: from torsrvs.snydernet.net (HELO localhost) ([91.213.8.236]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 04 Dec 2015 17:20:53 +0100 Message-ID: <1449246126.2558.72.camel@gnunet.org> From: Jeff Burdges To: tls@ietf.org Date: Fri, 04 Dec 2015 17:22:06 +0100 In-Reply-To: <071D813D-E2DD-48B6-8A53-52DC919F7401@gmail.com> References: <56586A2F.1070703@gmail.com> <565DBC63.5090908@gmail.com> <565DC935.2040607@gmail.com> <565E1517.3060209@gmail.com> <9BDDC23D-1039-4C75-BF32-57330317BCAB@gmail.com> <7F6CAD8F92F54AD5A4F6B14D5F471740@buildpc> <071D813D-E2DD-48B6-8A53-52DC919F7401@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-bPYb8nsgMSy8nEy+9KRb" X-Mailer: Evolution 3.16.5-1 Mime-Version: 1.0 Archived-At: Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2015 16:33:15 -0000 --=-bPYb8nsgMSy8nEy+9KRb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bryan Ford wrote :=20 > 2. The 2-byte length field in each record's header no longer=20 > indicates the length of the *current* record but instead indicates > the length of the *next* record. The length of the first record > might be defined in a new field we add to the handshake/key-exchange > protocol, or it might simply be set to some well-known standard first > record size. Using a standard size for the first message sounds like an amazingly good idea, irrespective of whether the idea of each message containing the next message's size works out. Any thoughts on how big this first message should be?=20 Jeff --=-bPYb8nsgMSy8nEy+9KRb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJWYb2uAAoJEKusf9HMEAp0M34QAOHPHEiCh68Tk5tcfey92HrC wmm1o2y04zo2fNfFvs0gmsQlr70FsPPUPlk9ptXwuWFnx+YKEOO1muBdAqkXL8E7 zHDTp+Qi9vFlUbfXFgYdEeJ5haNO3lx8kJBsR6qDoN7ag3asbzz+1do16muyAHwy iYzZNg6GPWHpadd6Gknjce1twEniRkult5DYkzuob+zl4Vhyt6mU+2H20rPOL5x4 v7pgzqbuDJgGfozFvqhT0qIs0uRWSsRwH84QwIkSzR+ZOKB9y6thyYJDeQuD/5Aj ZRgdWi0smuxDAzLLT8q/WPXIZm/aeg0TviwHUUdJZCsOTqaE/EMLQyVy7sdtOMec 5kThmd5u13SSGKovrd3D/S7ujJMA2Lc2dqaYOr8xVRvx/taRNXKqhitUPgosF5Lj 8zLNByZ4mkJ8y4ow27Njjn0QkcsbO7pGxVzo8cPiT+pGNKpIPBi//cXPGiI1ozmU d1o63lTqptHBcoYkfqFczOkpmlUMqYsbMmpC5nRgde1XLXj0jsLvmocvJI08OJrt amzjvO+GMaCqEckNkmTKd/1jZmLsJPZWG1S44hjAEH/8D6UlSFA+xW6rlqqyjNsf ZZBlsVz/pAKL1x20TCNFsoYWOeONGZzXqrBYGUb582M8HgwluqCLFevu9rt8xawk pGZnUefTKDV7vQ5cxB4s =892X -----END PGP SIGNATURE----- --=-bPYb8nsgMSy8nEy+9KRb-- From nobody Fri Dec 4 09:45:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39A41A902E for ; Fri, 4 Dec 2015 09:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-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 KNaDK2RL0pVM for ; Fri, 4 Dec 2015 09:45:33 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9F11A9008 for ; Fri, 4 Dec 2015 09:45:33 -0800 (PST) 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 (Postfix) with ESMTPS id 96461C0A15F3; Fri, 4 Dec 2015 17:45:32 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-105.brq.redhat.com [10.34.0.105]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB4HjVrE005168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Dec 2015 12:45:32 -0500 From: Hubert Kario To: Kurt Roeckx Date: Fri, 04 Dec 2015 18:45:25 +0100 Message-ID: <2348468.lpGyMim7ub@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.6-201.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <20151016203610.GA5596@roeckx.be> References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <2977428.j4DNTR9LXR@pintsize.usersys.redhat.com> <20151016203610.GA5596@roeckx.be> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6502285.HHKI0eEsQq"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2015 17:45:39 -0000 --nextPart6502285.HHKI0eEsQq Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 16 October 2015 22:36:10 Kurt Roeckx wrote: > On Fri, Oct 16, 2015 at 04:05:34PM +0200, Hubert Kario wrote: > > On Friday 16 October 2015 09:16:01 Watson Ladd wrote: > > > Unfortunately I don't know how to verify this. Can miTLS cover > > > this > > > case? > >=20 > > you mean, you want an implementation that can insert application > > data in any place of the handshake? >=20 > Have you tried running any of your tests against miTLS? Yes, I finally did miTLS does accept Application Data when it is send between Client Hello= =20 and Client Key Exchange and rejects it when it is sent between Change=20= Cipher Spec and Finished. Though I will need to modify tlsfuzzer a bit more before I will be able= =20 to publish an automated test case for that* * - miTLS writes HTTP responses in a line-by-line basis, making=20 handling of its responses a bit more complex =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart6502285.HHKI0eEsQq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJWYdE1AAoJEJKo0bgB0vX1UscP/05uAtQOI0Y+O5x8FL9gi8Yz Rnv67EkHu0d028rA6cPuUJ+QTp+6HwSt5dDFyYT3WihDBa+I9u4I5Dsa3Y27hHZ3 9u534Sj/JdAMfoQ/TXXMiupd2jrAc3n2dyZLHEw/zdLeXL7dQYd8zOmmuJFKVE7L kkD88o1kt8Md4/4pZoM0CP4VxHsKoxaYQ2OMdit1IgXv97cumdEqmmMwF8gUO40O 4NOYL1zPEYVfToxz2PvyN3OD3QtbGC32MRj6mCK6tgrpUrvWniZgMU+tdCk7FClN vDKeZM4CYa+5KsX53Ar24Q6TBAJDDGdOs7MIhQhhAp2/w4m07vrBeLbtzF7E/3aa rEnQJYpzZSbrmul4LvBIlgv4KrIFVyhPpK8+3VNkRdbhg2tNtx5z3WhJ1PZrshxd ZsdWd4pabvBfnR6T2ID2kvnuT7wp6vK5DPLXMXrxmdmWbv3qCimrkSp3EzYlm0Zm uvV2vC+TJerqnk1r1P9XYxNw8qLy/lYq0uk0HrUzb642RWkWO8HL4Gnj6Q+P3SvC gf7oCcNXFLC3Fvx7X1014v7j7abus0zwE0nbNeCctrOlpr//gdun9XULYaDRR5Zc +EDOESSrddEZzaoNWgaXEifa96Kiba/Pczqs/hyF/5+rGVuKwg/uy+n9ra4qLlNZ XF6W8MpP2bplfCWkYqbZ =b2k7 -----END PGP SIGNATURE----- --nextPart6502285.HHKI0eEsQq-- From nobody Fri Dec 4 10:17:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2626C1B2B2B for ; Fri, 4 Dec 2015 10:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.611 X-Spam-Level: X-Spam-Status: No, score=-4.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-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 04hYDQgeFMYR for ; Fri, 4 Dec 2015 10:17:39 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676AB1B2B03 for ; Fri, 4 Dec 2015 10:17:39 -0800 (PST) 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 (Postfix) with ESMTPS id D7C36A37EF; Fri, 4 Dec 2015 18:11:10 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-105.brq.redhat.com [10.34.0.105]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB4IB8Ta010969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Dec 2015 13:11:10 -0500 From: Hubert Kario To: tls@ietf.org Date: Fri, 04 Dec 2015 19:11:08 +0100 Message-ID: <1819508.BiWZzO1XF0@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.6-201.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <20151204005208.5b9aad75@pc1> References: <20151204005208.5b9aad75@pc1> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1639127.6nfhmb551X"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [TLS] Fresh results X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2015 18:17:41 -0000 --nextPart1639127.6nfhmb551X Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 04 December 2015 00:52:08 Hanno B=C3=B6ck wrote: > On Thu, 3 Dec 2015 18:45:14 -0500 >=20 > Watson Ladd wrote: > > On Tue, Dec 1, 2015 at 3:02 PM, Hanno B=C3=B6ck w= rote: > > > So as long as you make sure you implement all the proper > > > countermeasures against that you should be fine. (Granted: This i= s > > > tricky, as has been shown by previous results, even the OpenSSL > > > implementation was lacking proper countermeasures not that long > > > ago, > > > but it's not impossible) > >=20 > > Can you describe the complete set of required countermeasures, and > > prove they work comprehensively? What if the code is running on > > shared hosting, where much better timing attacks are possible? > > What's shocking is that this has been going on for well over a > > decade: the right solution is to use robust key exchanges, and yet > > despite knowing that this is possible, we've decided to throw patch= > > onto patch on top of a fundamentally broken idea. There is no fix > > for PKCS 1.5 encryption, just dirty hacks rooted in accidents of > > TLS. >=20 > No disagreement here. >=20 > The thing is, we have a bunch of difficult options to choose from: >=20 > * Fully deprecate RSA key exchange. > The compatibility costs of this one are high. They are even higher > considering the fact that chrome wants to deprecate dhe and use rsa a= s > their fallback for hosts not doing ecdhe. ecdhe implementations > weren't widespred until quite recently. A lot of patent foo has e.g. > stopped some linux distros from shipping it. Then maybe Chrome should reconsider. I think we're overstating the compatibility costs. very few widely deployed implementations (with the exception of the lon= g=20 deprecated Windows XP) lack support for DHE_RSA *and* ECDHE_RSA at the=20= same time =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart1639127.6nfhmb551X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJWYdc8AAoJEJKo0bgB0vX19VsQAIXNmErTWLonjKuG8YK1glzE /Jwn2GHxgocfwzSd4R9KWUWfI4VgTkXJ5LR49jnSJlle3AESe4YEeo+Pi1mYl36H PbufhJ9G+3DS0TcRkRsZbgfadxXBc6GWOLyPIo1ZLL9gFl7RLVmrTA/ntziQgt+g QP/Rksr5C11uLE+j5GUu+eZyik0LTsiTDEItH9I/6XOFjZaaqu/0vqwBO/4eKJCq kJ6XdsmM3PtObg5Do6rn+bC4qukFtoTL5ZHLqyNeu9eYuWgsERAErVi6d4UrG17O stbdXziSEnWFskItlkY8fRwDtpTXbfDUHC6Cdd6WLK5HArCndXZ+o+8RD6jGjiFt XaGAtI4Tub0NNLEJNLoxF8RGUzarvhouP0zCT7o45KBEDxmvSk77lOspArcazHp8 ryZ2p1ZeSEUUtxwHYyo0v4YhX6h3Jw34lA/ywJKOlRAH1xdIKoERc7RPZnirDCAQ 40XwufLc1fQ78rXJOW0Np5alNTQaHKNC5Hg4mfkUQBvwxoszdGAW5G1jCaxko9im Ki/Jxb1CxPDsSFMcu9VOxnRi+CXDVrvQrfGZ11VWJsjYY4/MR8QqpsHDYO6SDsjI 9mtBZXaYSZwnj4w6okuq+9dqcxhjD6aZZ083787IXTZqeMHqdrqybPLRaDBSn8aj d+/pGUnkiymrwdUHC6tY =L/Hf -----END PGP SIGNATURE----- --nextPart1639127.6nfhmb551X-- From nobody Fri Dec 4 11:38:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1F01B32D1 for ; Fri, 4 Dec 2015 11:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.912 X-Spam-Level: X-Spam-Status: No, score=0.912 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, MANGLED_BACK=2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 KcwUCHxnf069 for ; Fri, 4 Dec 2015 11:38:52 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557441B32D5 for ; Fri, 4 Dec 2015 11:38:52 -0800 (PST) Received: by igcmv3 with SMTP id mv3so42964732igc.0 for ; Fri, 04 Dec 2015 11:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=8r8yLE6DzGlSBhNWKaor+RO8P/XNYWrDlzc1yxZvJ8U=; b=fBHvYhYUKTJ+KaAgg89eaJbWrfjDVKfi5mOLGKJtOzi8OzBMwjHXyzF1GkSOg5IWry j5OpMKWkrCecd2Q42UfTl5VadVUVr7MrZ2f5vXbQvliSD/am7f32YJ95wwbV1QsBx3cv 089DdxwFNmW+i9tQhPqyboeruKzSm0BFB8TTw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=8r8yLE6DzGlSBhNWKaor+RO8P/XNYWrDlzc1yxZvJ8U=; b=VvStBYa+LN6TemCc5Ca3PJxc61kMnn7yj0AeO/s1VxeTxavEQdCIMW+S5gmM/gXvo8 gpm0gkaDsqzPN3Inr1ujAUNQcf++WtWfv4cwCYwm7FCmWiwj8h4GJ3B0ALHaGCOTbyfU rpgGirIaj7irUULV5M1TkCwWM73HNAvNj27A9a4dUXnplofrE96vVHVsw2L7U9aqgwYs /qmxL1fYkd57Z5N58yyureGw209W5TKYZC72LIqPNm9KUTlhEK9orSv4fQlLSKN7Ggdd DEJOEgPUo2sFd2fNDhbFgdWY2jNLJf2uqumU+6QzpgJc0lxWHHadsyhqyROOURMNiG8D PGBw== X-Gm-Message-State: ALoCoQmPffUpcZZ3Zw7BZf7bBqswJMxBmk/CEFscV5fPt2uQQOItdmGKioUBW59KuvDlgjQaTQde0QigQpYYUeVOT0NkFKmUCs4lopOw7x5TwigJ1wpdk4Y= X-Received: by 10.50.155.65 with SMTP id vu1mr6066470igb.11.1449257931571; Fri, 04 Dec 2015 11:38:51 -0800 (PST) MIME-Version: 1.0 References: <20151204005208.5b9aad75@pc1> <1819508.BiWZzO1XF0@pintsize.usersys.redhat.com> In-Reply-To: <1819508.BiWZzO1XF0@pintsize.usersys.redhat.com> From: David Benjamin Date: Fri, 04 Dec 2015 19:38:39 +0000 Message-ID: To: Hubert Kario , tls@ietf.org Content-Type: multipart/alternative; boundary=001a11346410336207052617a8e6 Archived-At: Subject: Re: [TLS] Fresh results X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2015 19:38:54 -0000 --001a11346410336207052617a8e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 4, 2015 at 1:17 PM Hubert Kario wrote: > On Friday 04 December 2015 00:52:08 Hanno B=C3=B6ck wrote: > > * Fully deprecate RSA key exchange. > > The compatibility costs of this one are high. They are even higher > > considering the fact that chrome wants to deprecate dhe and use rsa as > > their fallback for hosts not doing ecdhe. ecdhe implementations > > weren't widespred until quite recently. A lot of patent foo has e.g. > > stopped some linux distros from shipping it. > > Then maybe Chrome should reconsider. > Note that Apple has already removed DHE cipher suites from Safari in the latest OS X and iOS releases, so advertising only DHE is already infeasible for most servers. I don't think telling servers to disable RSA ciphers and only advertise DHE_RSA ciphers makes much sense. The set of servers which... 1. Are willing to disable plain RSA. 2. Don't have ECDHE support. 3. Are unwilling to take updates and get ECDHE support. 4. Support DHE support *with a sensible group*. 5. Are willing to deploy DHE with said sensible group despite the compatibility and performance hit. ...is certainly all but nil. David I think we're overstating the compatibility costs. > > very few widely deployed implementations (with the exception of the long > deprecated Windows XP) lack support for DHE_RSA *and* ECDHE_RSA at the > same time > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech > Republic_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11346410336207052617a8e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 4,= 2015 at 1:17 PM Hubert Kario <hkar= io@redhat.com> wrote:
On Fri= day 04 December 2015 00:52:08 Hanno B=C3=B6ck wrote:
> * Fully deprecate RSA key exchange.
> The compatibility costs of this one are high. They are even higher
> considering the fact that chrome wants to deprecate dhe and use rsa as=
> their fallback for hosts not doing ecdhe. ecdhe implementations
> weren't widespred until quite recently. A lot of patent foo has e.= g.
> stopped some linux distros from shipping it.

Then maybe Chrome should reconsider.

No= te that Apple has already removed DHE cipher suites from Safari in the late= st OS X and iOS releases, so advertising only DHE is already infeasible for= most servers.

I don't think telling servers t= o disable RSA ciphers and only advertise DHE_RSA ciphers makes much sense. = The set of servers which...

1. Are willing to disa= ble plain RSA.
2. Don't have ECDHE support.
3. Are = unwilling to take updates and get ECDHE support.
4. Support DHE s= upport *with a sensible group*.
5. Are willing to deploy DHE with= said sensible group despite the compatibility and performance hit.

...is certainly all but nil.

Dav= id

I think we're overstating the compatibility costs.

very few widely deployed implementations (with the exception of the long deprecated Windows XP) lack support for DHE_RSA *and* ECDHE_RSA at the
same time

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic___= ____________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a11346410336207052617a8e6-- From nobody Fri Dec 4 12:59:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1291A1B20 for ; Fri, 4 Dec 2015 12:59:20 -0800 (PST) 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, 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 beIW6R_V9Z_Z for ; Fri, 4 Dec 2015 12:59:18 -0800 (PST) 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 290441A007C for ; Fri, 4 Dec 2015 12:59:18 -0800 (PST) Received: from hebrews (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 61FDF38F00 for ; Fri, 4 Dec 2015 12:59:17 -0800 (PST) From: "Jim Schaad" To: Date: Fri, 4 Dec 2015 12:56:31 -0800 Message-ID: <11f501d12ed6$41150270$c33f0750$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdEu0JalwPblztfJSXu/VFHTM/aR9A== Content-Language: en-us Archived-At: Subject: [TLS] Analysis of encrypting the headers - what is the length X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Dec 2015 20:59:20 -0000 I will start by re-iterating my initial position that I would prefer that the DTLS and TLS analysis is going to be the same in terms of masking the header information. So I decided to do some thought experiments about what happens if the length were to be encrypted and how many different situations does this not appear to help the situation. DTLS - Given that most DTLS situations are going to want to keep the block of data sent small, there is no to little incentive to send multiple DTLS blocks in a single UDP packet. This means that the length of the encrypted data is going to be easily found based on the length of the UDP packet. One can probably make some significantly accurate guesses about what the header fields are going to be for a DTLS packet, but I would assume that even if the key could be determined it would not compromise the keys used in protecting the D/TLS content itself. TLS w/ lock step protocol - Think about using TLS with a lock step protocol such as exists for POP where you always have a situation where the client sends a request and the server sends a response. Even with the length field encrypted a traffic analysis is going to be able to determine the length of all of many of the messages based on the amount of data that is flowing from each of the end-points. Thus with POP I can make a good guess about the length your password just by looking at the traffic being sent in terms of raw byte counts even without the length being directly available. TLS w/ time breaks between operations - Think about doing browsing on a web site. I read a page, which takes time, and then I click a link. Looking just at the traffic flow I can make a really good guess about the length of the link that you just sent to the server based on the number of bytes that are sent from the client to the server before the server starts chattering. Any protocol where there are going to be times where there is silence followed by a request and then responses is going to all for a relatively easy guess about the length of the request based just on the number of bytes in the stream. These are all situations where if one say - My attack model is that exposing the length of the encrypted data allows the attacker to obtain significant information about what I am sending - then the simple expedient of encrypting the header information is clearly insufficient to deal with the attack proposed. Additional steps need to be taken as well. For example sending all of the randomly updating adware back on the same TLS channel to prevent time breaks from occurring. (What a horrid idea of using adware as a method of preventing attacks.) I believe that this is the type of analysis that Peter is looking for in terms of what is the attack you are trying to prevent, what does the proposed remedy actually do what you think it does. The situations above would all appear to be better dealt with padding of the plain text in some manner rather than encrypting the length field. Jim From nobody Fri Dec 4 17:45:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C781B3518 for ; Fri, 4 Dec 2015 17:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 saAClnX0_H0w for ; Fri, 4 Dec 2015 17:45:07 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0750.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::750]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B49911A1AFB for ; Fri, 4 Dec 2015 17:45:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xadr/Jw8XlmbgzlVEODK3ySwuDW8PayyArMQkpFETrE=; b=PRm5MaiWjMKp8SMzgx5+jaw1Z2aYhbi9ZARcnCa5OwYZTf9/IfM9V7vA1EITkjCasApYqr6vqZQZ6H1md8H+5C09EXCYdUKLHdxBcaAv53sT9bIpz6Bmb++cn926XSHNh84YT2tUtg9fIl9ovVhRZ4+patvACDyUpH/WI5xrGtw= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0656.namprd03.prod.outlook.com (10.160.96.18) with Microsoft SMTP Server (TLS) id 15.1.337.19; Sat, 5 Dec 2015 01:44:47 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0331.023; Sat, 5 Dec 2015 01:44:48 +0000 From: Christian Huitema To: Jim Schaad , "tls@ietf.org" Thread-Topic: [TLS] Analysis of encrypting the headers - what is the length Thread-Index: AdEu0JalwPblztfJSXu/VFHTM/aR9AALH1yg Date: Sat, 5 Dec 2015 01:44:47 +0000 Message-ID: References: <11f501d12ed6$41150270$c33f0750$@augustcellars.com> In-Reply-To: <11f501d12ed6$41150270$c33f0750$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [131.107.147.15] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0656; 5:ZY7defFSWvWwv/e+CyYXhqmXHj4hiqlZgszmdg81EZf0+onYWqeg1qyBbpbmZKUba0DBe9CBp2dTMvuNWq64RWWjjKZhUy18UG7fZRu9Q1KjAQ2bl4qocoSq26MVaPEV/sFkSKEUxhyjo+hPcUG91g==; 24:STlFBcXRlu21E2SoqPKm0frN7nIhY5L6L8pYpesjaJ2GgCKEDpl6FtEPp8YJbbfcCpvXPLEZP7QzAS/32uH0br4aDqQasVJzRPrzguYY8nA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0656; x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:DM2PR0301MB0656; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656; x-forefront-prvs: 07817FCC2D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(76104003)(24454002)(199003)(377454003)(10400500002)(5005710100001)(86362001)(5002640100001)(5008740100001)(10290500002)(1220700001)(5003600100002)(8990500004)(10090500001)(1096002)(19580395003)(19580405001)(86612001)(74316001)(6116002)(102836003)(3846002)(586003)(76176999)(50986999)(54356999)(5004730100002)(87936001)(5001960100002)(66066001)(106356001)(2900100001)(101416001)(122556002)(33656002)(105586002)(2950100001)(40100003)(2501003)(99286002)(15975445007)(92566002)(77096005)(81156007)(189998001)(97736004)(5001770100001)(551544002)(107886002)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0656; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2015 01:44:47.9054 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0656 Archived-At: Subject: Re: [TLS] Analysis of encrypting the headers - what is the length X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2015 01:45:09 -0000 On Friday, December 4, 2015 12:57 PM, Jim Schaad wrote: > To: tls@ietf.org > Subject: [TLS] Analysis of encrypting the headers - what is the length > ... >=20 > DTLS - Given that most DTLS situations are going to want to keep the blo= ck > of data sent small, there is no to little incentive to send multiple DTLS= blocks > in a single UDP packet. This means that the length of the encrypted data= is > going to be easily found based on the length of the UDP packet. > One can probably make some significantly accurate guesses about what the > header fields are going to be for a DTLS packet, but I would assume that > even if the key could be determined it would not compromise the keys used > in protecting the D/TLS content itself. Some DTLS applications that care about privacy. An example is DPRIVE -- DNS= over DTLS, or over TLS. The length of the packets matter. The length of ci= pher-texts for query and responses can enable guesses on the length of the = name being looked at, and that's precisely what DPRIVE is trying to prevent= . But then the answer is not to encrypt the length, because as Jim says it = can be deduced from the size of the UDP packets, or even the patterns of th= e TCP stream. The solution instead is padding, either using the TLS 1.3 mec= hanism, or using the DNS padding option that DPRIVE is standardizing.=20 There are debates on how much to pad exactly, e.g. to the max MTU or to som= e logarithmic scale. Will probably take some time to assess the best strate= gy. But it is going to happen. -- Christian Huitema > TLS w/ lock step protocol - Think about using TLS with a lock step protoc= ol > such as exists for POP where you always have a situation where the client > sends a request and the server sends a response. Even with the length fi= eld > encrypted a traffic analysis is going to be able to determine the length = of all > of many of the messages based on the amount of data that is flowing from > each of the end-points. Thus with POP I can make a good guess about the > length your password just by looking at the traffic being sent in terms o= f raw > byte counts even without the length being directly available. >=20 > TLS w/ time breaks between operations - Think about doing browsing on a > web site. I read a page, which takes time, and then I click a link. Loo= king just > at the traffic flow I can make a really good guess about the length of th= e link > that you just sent to the server based on the number of bytes that are se= nt > from the client to the server before the server starts chattering. > Any protocol where there are going to be times where there is silence > followed by a request and then responses is going to all for a relatively= easy > guess about the length of the request based just on the number of bytes i= n > the stream. >=20 > These are all situations where if one say - My attack model is that expos= ing > the length of the encrypted data allows the attacker to obtain significan= t > information about what I am sending - then the simple expedient of > encrypting the header information is clearly insufficient to deal with th= e > attack proposed. Additional steps need to be taken as well. For example > sending all of the randomly updating adware back on the same TLS channel > to prevent time breaks from occurring. (What a horrid idea of using adwa= re > as a method of preventing attacks.) >=20 > I believe that this is the type of analysis that Peter is looking for in = terms of > what is the attack you are trying to prevent, what does the proposed reme= dy > actually do what you think it does. The situations above would all appea= r to > be better dealt with padding of the plain text in some manner rather than > encrypting the length field. >=20 > Jim >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie > tf.org%2fmailman%2flistinfo%2ftls&data=3D01%7c01%7chuitema%40microsof > t.com%7c329977d637c04d729a5708d2fcedcbc2%7c72f988bf86f141af91ab2 > d7cd011db47%7c1&sdata=3DcNl1i6bnNSNrsPR%2bZ9JHOiepttgz6nRmoIQn7en > Exto%3d From nobody Fri Dec 4 21:16:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807691A002A for ; Fri, 4 Dec 2015 21:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_BACK=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 YRj1LNhpAMiQ for ; Fri, 4 Dec 2015 21:16:01 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93F31A0029 for ; Fri, 4 Dec 2015 21:16:00 -0800 (PST) Received: by pacwq6 with SMTP id wq6so19509540pac.1 for ; Fri, 04 Dec 2015 21:16:00 -0800 (PST) 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=QV2iOWLaa2tj9QKjZt4OKZsSpDbiZjjJqFaPKiit4MQ=; b=aXzgWIp9pLL9p8HCLsyp1OnF/UOSZMSN0I2/SFFEgOSdcRMCHXSqmSf8tDRxnrKMhp 8heHnr/jFeGw3rWdi2ovC+NvsoK7sYqmXgdYWTr6GNGb0z9xvElIg2C8NHYIKKagRjLA WSr6s85XlIjAlCoJfRscXvnXjaLPcqNG3ek0FRq1ZNKzn28YnFjCLAWQMEgj7/A3KLhb 2EnVeEjlBwu3CQWQUrFjzywkvyaWGgUcEXPluhwZZedKIYIWz++LoOCpOHunf+QAHWMJ +E5q9SoO5W1tTCSxpWjyYFAYFwE62brKYWIFm+d2kblQTGs06v/ZADkR8S4vNoNaehsR 01Cw== X-Received: by 10.67.5.98 with SMTP id cl2mr26988187pad.157.1449292560212; Fri, 04 Dec 2015 21:16:00 -0800 (PST) Received: from [10.0.1.7] (c-50-136-214-180.hsd1.ca.comcast.net. [50.136.214.180]) by smtp.gmail.com with ESMTPSA id n16sm20353435pfa.53.2015.12.04.21.15.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Dec 2015 21:15:59 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Fabrice Gautier X-Mailer: iPhone Mail (13A340) In-Reply-To: <1819508.BiWZzO1XF0@pintsize.usersys.redhat.com> Date: Fri, 4 Dec 2015 21:20:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151204005208.5b9aad75@pc1> <1819508.BiWZzO1XF0@pintsize.usersys.redhat.com> To: Hubert Kario Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Fresh results X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2015 05:16:02 -0000 > On Dec 4, 2015, at 10:11, Hubert Kario wrote: >=20 >> On Friday 04 December 2015 00:52:08 Hanno B=C3=B6ck wrote: >> On Thu, 3 Dec 2015 18:45:14 -0500 >>=20 >> Watson Ladd wrote: >>>> On Tue, Dec 1, 2015 at 3:02 PM, Hanno B=C3=B6ck wrote= : >>>> So as long as you make sure you implement all the proper >>>> countermeasures against that you should be fine. (Granted: This is >>>> tricky, as has been shown by previous results, even the OpenSSL >>>> implementation was lacking proper countermeasures not that long >>>> ago, >>>> but it's not impossible) >>>=20 >>> Can you describe the complete set of required countermeasures, and >>> prove they work comprehensively? What if the code is running on >>> shared hosting, where much better timing attacks are possible? >>> What's shocking is that this has been going on for well over a >>> decade: the right solution is to use robust key exchanges, and yet >>> despite knowing that this is possible, we've decided to throw patch >>> onto patch on top of a fundamentally broken idea. There is no fix >>> for PKCS 1.5 encryption, just dirty hacks rooted in accidents of >>> TLS. >>=20 >> No disagreement here. >>=20 >> The thing is, we have a bunch of difficult options to choose from: >>=20 >> * Fully deprecate RSA key exchange. >> The compatibility costs of this one are high. They are even higher >> considering the fact that chrome wants to deprecate dhe and use rsa as >> their fallback for hosts not doing ecdhe. ecdhe implementations >> weren't widespred until quite recently. A lot of patent foo has e.g. >> stopped some linux distros from shipping it. >=20 > Then maybe Chrome should reconsider. >=20 > I think we're overstating the compatibility costs. >=20 > very few widely deployed implementations (with the exception of the long=20= > deprecated Windows XP) lack support for DHE_RSA *and* ECDHE_RSA at the=20 > same time The main issue with DHE_RSA is that there are still too many servers which w= ill use short DHE group (<1024 bits). When connecting to those servers, usin= g RSA is (presumably) safer. =46rom a compatibility aspect it's much simpler and safer to just disable DH= E completely than to try to enforce a DHE limit, which would require a fallb= ack connection to RSA. -- Fabrice.=20 > --=20 > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Dec 5 07:32:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FC51B2AF8 for ; Sat, 5 Dec 2015 07:32:41 -0800 (PST) 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, 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 paeR1trRFFKV for ; Sat, 5 Dec 2015 07:32:40 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4161B2AF7 for ; Sat, 5 Dec 2015 07:32:40 -0800 (PST) Received: by oixx65 with SMTP id x65so80686757oix.0 for ; Sat, 05 Dec 2015 07:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=0V+p33Q5IpbQ+fqO9Y7P0cyQSJxLT/YKBkdsR1lRPTU=; b=AQp8d+xu7KaH28ok31XQCt44cN8sp4BTm7W7FQewSLXhTgC2achgf2wO9kX4ST2UKJ SnxvvXwZum8fRgeCQ7j8sl2pw8fflntdNaMiKx0K8f4Awh1+VnzMFtcKngHwQmd8dWib dwRIwSCpxTS4g3kHGyUmk3HvKbacEQFPIBFNrhfTDWUPti8NR0W3unY4tggxdtSWO+jn GVYP9X4s5j8o1JnnyX4wjvgmfIRz0nF/QpZYnV/ZMMxDlWe9x9DwNmarBJ4okMKvHW+l wggmO5cFh9K+3mvQpZWSDDvdOiZ3qe7HDgtnbfs1kmcL44DyL8gzPx0RnFF3XknzCcSX Z8cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=0V+p33Q5IpbQ+fqO9Y7P0cyQSJxLT/YKBkdsR1lRPTU=; b=FY1N6fLvM5dFt+k8B2jPQYutwVJFSxutRC3pGYbuGOLNDrI+tQzawxKzjDSEZ7BHC3 U8uguNaMI2EVPgjPQeaIwZc9YJlNYJUyei8ts8hyGWErgP10H6fH7M3+gAuvs0pI29lv uh/m88zB+5g6ZHQjrAgdePpbTV/9cvVOSX8alcanwrWNoo2bPkbFfRhexp2kH7vqIAf2 u4KS+BmMxTzhKx8GeMZRN0f5DY/6CmJavVhfuHarM59rJlbnG624YSlnHHBOszSDmSvY fPMXwjBlHJq63WWktDVAcOE7nbfVkYjNRfjgLMNEUOlTEBZpiBoIyOt5T5fr22BVrL00 H8nQ== X-Gm-Message-State: ALoCoQmjUewsVlEroFMq9ikt5UkqmQm3+LQcE9u8uJ18iIU2XlJONynYwjf3s5IzkxA6g6DqvhdH MIME-Version: 1.0 X-Received: by 10.202.208.83 with SMTP id h80mr16549941oig.74.1449329560221; Sat, 05 Dec 2015 07:32:40 -0800 (PST) Received: by 10.76.18.75 with HTTP; Sat, 5 Dec 2015 07:32:40 -0800 (PST) X-Originating-IP: [148.87.19.214] Date: Sat, 5 Dec 2015 23:32:40 +0800 Message-ID: From: Xuelei Fan To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113d2ed69990a80526285532 Archived-At: Subject: [TLS] The progress about theNegotiated FFDHE proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2015 15:32:42 -0000 --001a113d2ed69990a80526285532 Content-Type: text/plain; charset=UTF-8 Hi, Any one know why the negotiated FFDHE draft hang on MISSREF state for more than 180 days? http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ Thanks & Regards, Xuelei --001a113d2ed69990a80526285532 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Any one know why the negotiated FFD= HE draft hang on=C2=A0MISSREF state for more than 180 days?

<= /div>

Thanks & Regards,
<= div>Xuelei
--001a113d2ed69990a80526285532-- From nobody Sat Dec 5 07:43:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA521A700B for ; Sat, 5 Dec 2015 07:43:37 -0800 (PST) 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 Rp4tUCTGIP_g for ; Sat, 5 Dec 2015 07:43:35 -0800 (PST) Received: from filtteri2.pp.htv.fi (filtteri2.pp.htv.fi [213.243.153.185]) by ietfa.amsl.com (Postfix) with ESMTP id DBAF71A700A for ; Sat, 5 Dec 2015 07:43:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri2.pp.htv.fi (Postfix) with ESMTP id 573AC19C060; Sat, 5 Dec 2015 17:43:33 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri2.pp.htv.fi [213.243.153.185]) (amavisd-new, port 10024) with ESMTP id 2DNPiAdxWMhh; Sat, 5 Dec 2015 17:43:32 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id D06535BC002; Sat, 5 Dec 2015 17:43:32 +0200 (EET) Date: Sat, 5 Dec 2015 17:43:30 +0200 From: Ilari Liusvaara To: Xuelei Fan Message-ID: <20151205154330.GA25350@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] The progress about theNegotiated FFDHE proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2015 15:43:37 -0000 On Sat, Dec 05, 2015 at 11:32:40PM +0800, Xuelei Fan wrote: > Hi, > > Any one know why the negotiated FFDHE draft hang on MISSREF state for more > than 180 days? > > http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ Normatively depends on the false-start draft that isn't sent to the RFC-Editor yet. The specification itself is done and all the needed codepoints have been assigned. -Ilari From nobody Sat Dec 5 10:32:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4811B2BF4 for ; Sat, 5 Dec 2015 10:32:53 -0800 (PST) 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, HTML_MESSAGE=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 LAhHCbUwKgYB for ; Sat, 5 Dec 2015 10:32:51 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0441B2BF3 for ; Sat, 5 Dec 2015 10:32:51 -0800 (PST) Received: by ykdv3 with SMTP id v3so156409796ykd.0 for ; Sat, 05 Dec 2015 10:32:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type; bh=28bGt+QQm4g2Gsp7RpygEUzLT2hfGcihVOXs1mXGjLw=; b=dX2oM6Vgeyiv8guDo53Tlc6YPY2kI3CgGCDD6mKPLyM7j3XVXBQsopa/0/kfOr4GvY K8559eAqjxbL2fn/O9zeU15hVLCuTR1FEPlgAm+ea/XPaI2azwP8aanJIdXxnG7O8JXg 2E5FYI36Dz/spnq1zZfH73pGNfvhBgtImD4gyVUYE9D4WEdFcJ1OkH9eljaBqMcu5Cwt frYNo4qhygeab/VncaJJiqkreemCLMlG8zbGkQMtWm+j/tqJB0IbbRH+kkvg6vDFWtj3 G8QDXKVsXoM+Shdfy2s0m6xgJo0H7OqR47VYDTEmJsj7UuN+jNk6GGljUvvsWYpt5Lv4 B9sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=28bGt+QQm4g2Gsp7RpygEUzLT2hfGcihVOXs1mXGjLw=; b=QuuGysz2w4sUWxoA2LA2rzje5zmpei5qBOEaYlMi6cO/JguxljLSzUAwKKocs89/jN 2F45DNKtrUOmEP3DKONNv09GLQxtXbukp+Qc3grLpmiGe2876n3V/s6I/kBv/FH7uRmU 37KtVKpbdncDYh4cUPeUT6uagj8DP4XBY0uO9G9aUBIL5hbJSIK7P0dyjoLYccroJkHO m01GZHyEXO8kyhQO0jgiLnNCkh/5az47Ifl7ST6VTQyGbYz6PX54Xf2nCLRN7sNmB457 y216iUk//V35Dj2P5NwobJeohkHGADG/wW/82oL4JE0hAbvfiPY+z74Q4NEnfGnxGC+A T/6Q== X-Gm-Message-State: ALoCoQlKE0WQyS5KWlpfhsdxPm1HV6+PcmOVFRZDrp5mD9m6brQ59W4rESVzNSal36518XdFzRgT X-Received: by 10.129.46.84 with SMTP id u81mr15635258ywu.129.1449340370699; Sat, 05 Dec 2015 10:32:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Sat, 5 Dec 2015 10:32:11 -0800 (PST) From: Eric Rescorla Date: Sat, 5 Dec 2015 10:32:11 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11409380f4797505262ad9b9 Archived-At: Subject: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2015 18:32:53 -0000 --001a11409380f4797505262ad9b9 Content-Type: text/plain; charset=UTF-8 Subject: SNI Encryption Part XLVIII Folks, TL;DR. This message describes a technique for doing SNI encryption that just requires (re)adding EncryptedExtensions to the client's first flight [0] defining an extension that indicates "tunnelled TLS" and (maybe) a new TLS content type. We would only tunnel the first flight and everything else would be handed off to the hidden service. This seems like the minimal change to enable Encrypted SNI while retaining our existing analytical frame for the rest of TLS. DETAILS During the discussion of SNI Encryption in Yokohama, Deb Cooley argued that rather than messing with TLS to allow SNI encryption, we should just tunnel TLS in TLS. A number of people objected to this on the grounds of the performance cost for the gateway because it has to encrypt and decrypt everything. After the meeting, Martin Thomson suggested a modification to the tunnelling proposal that removes this cost. The key observation is that if we think of the 0-RTT flight as a separate message attached to the handshake, then we can tunnel a second first flight in it. Here's the idea: Client Gateway Hidden ClientHello#1 + KeyShare + EarlyDataIndication + SNI = gateway (Finished) ( ClientHello#2 + KeyShare + SNI = hidden // ) (end_of_early_data alert) ----> ClientHello#2 + KeyShare + SNI = hidden ----> ServerHello + KeyShare {EncryptedExtensions} {ServerConfiguration*} {Certificate*} {CertificateRequest*} {CertificateVerify*} <------------------------------- {Finished} {Finished} -------------------------------> Key to brackets: () encrypted with Client->Gateway 0-RTT key (either handshake or data) <> encrypted with Client->Hidden 0-RTT key {} encrypted with Client->Hidden 1-RTT handshake The way this works is that the Gateway decrypts the *data* in the client's first flight, which is actually ClientHello#2 from the client, containing the true SNI and then passes it on to the, Hidden server. However, the Hidden server responds with its own ServerHello which the Gateway just passes unchanged, because it's actually the response to ClientHello#2 rather than to ClientHello#1. As long as ClientHello#1 and ClientHello#2 are similar (e.g., differing only in the client's actual share (though of course it must be in the same group)), SNI, and maybe EarlyDataIndication), then an attacker should not be able to distinguish these cases. Notes on several obvious technical issues: 1. How does the Gateway distinguish this case from where the initial flight is actual application data? See below for some thoughts on this. 2. Can we make this work with 0-RTT data from the client to the Hidden server? I believe the answer here is "yes", because the server's EarlyDataIndication does not carry the configuration_id. I just didn't show it in the diagram because it was already getting complicated. 3. What happens if the Gateway server doesn't gateway, e.g., because it has forgotten the ServerConfiguration? In that case, the client gets a handshake with the Gateway, which it will have to determine via trial decryption. At this point the Gateway supplies a ServerConfiguration and the client can reconnect as above. 4. What happens if the client does 0-RTT inside 0-RTT (as in #2 above) and the Hidden server doesn't recognize the ServerConfiguration in ClientHello#2? In this case, the client gets a 0-RTT rejection and it needs to do trial decryption to know whether the rejection was from the Gateway or the Hidden server. The big advantage of this design compared to the designs we were discussing in Yokohama is that it requires effectively no changes to TLS. The only thing you need is a way to signal to the Gateway server that the encrypted application data is actually a ClientHello which is intended for the hidden service. The two most obvious designs are: - Have an EncryptedExtension which indicates that the inner data is tunnelled. - Have a "tunnelled" TLS content type. In the interest of explicit signaling I think EncryptedExtensions is best but we either need to require that all TLS 1.3 implementations handle that extension or *also* have a new content type, because otherwise it might be possible for an attacker to craft an inner ClientHello which was processable in part as an upper-level protocol message, which could be bad. The major disadvantage of this overall design strategy (however it's signaled) is that it's somewhat harder to implement in the co-tenanted cases than the most trivial "RealSNI" scheme. That means that it's somewhat less likely that servers will implement it "by default" and more likely that they will have to take explicit effort to allow Encrypted SNI. Conversely, however, these modes (aside from a server with a single wildcard or multi-SAN cert) involve more changes to TLS to deal with issues like "what is the server cert that is digested into the keys", and that requires more analysis, so there is an advantage to deferring that. If we have EncryptedExtensions in the client's first flight it would be possible to add RealSNI later if/when we had clearer analysis for that case. Important note: this whole discussion punts the question of how a client knows that it can do any of this stuff. My assumption here is that the client learns it from the Hidden server in some unprotected connection or via some side channel (e.g., DNS). -Ekr [0] We need to do this anyway because we need to have stuff like "this is the ALPN for this first flight". --001a11409380f4797505262ad9b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Subject: SNI Encryption Part XLVIII

Folks,

TL;DR.
This message descr= ibes a technique for doing SNI encryption that just
requires (re)= adding EncryptedExtensions to the client's first flight [0]
d= efining an extension that indicates "tunnelled TLS" and (maybe) a= new
TLS content type. We would only tunnel the first flight and = everything
else would be handed off to the hidden service. This s= eems like the
minimal change to enable Encrypted SNI while retain= ing our existing
analytical frame for the rest of TLS.
=

DETAILS
During the discussion of SN= I Encryption in Yokohama, Deb Cooley
argued that rather than mess= ing with TLS to allow SNI encryption,
we should just tunnel TLS i= n TLS. A number of people objected
to this on the grounds of the = performance cost for the gateway
because it has to encrypt and de= crypt everything.

After the meeting, Martin Thomso= n suggested a modification to the
tunnelling proposal that remove= s this cost. The key observation is
that if we think of the 0-RTT= flight as a separate message attached to
the handshake, then we = can tunnel a second first flight in it. Here's
the idea:

=C2=A0Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gateway =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hidden

=C2=A0ClientHello#1
=C2=A0 + KeyShare
=C2=A0 + EarlyD= ataIndication
=C2=A0 + SNI =3D gateway
=C2=A0(Finished)=
=C2=A0(
=C2=A0 =C2=A0ClientHello#2
=C2=A0 = =C2=A0 + KeyShare
=C2=A0 =C2=A0 + SNI =3D hidden
=C2=A0= =C2=A0<Finished> =C2=A0 =C2=A0 =C2=A0 =C2=A0//=C2=A0
=C2= =A0)
=C2=A0(end_of_early_data alert) =C2=A0----> =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0ClientHello#2 =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+ KeyShare
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ SNI =3D hidden
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<Finished> =C2=A0 =C2=A0 =C2=A0= =C2=A0---->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Se= rverHello
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 + KeySha= re
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0{EncryptedExtensions}
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {ServerConfi= guration*}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {Certificate*}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0{CertificateRequest*}
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {Certificate= Verify*}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0<------------------------------- =C2=A0 {Finished}
{Finished} =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --------------------= ----------->


Key to brackets:

=C2=A0 () encrypted with Client->Gateway 0-RTT ke= y (either handshake or data)
=C2=A0 <> encrypted with Clien= t->Hidden 0-RTT key
=C2=A0 {} encrypted with Client->Hidden= 1-RTT handshake


The way this works= is that the Gateway decrypts the *data* in the
client's firs= t flight, which is actually ClientHello#2 from the
client, contai= ning the true SNI and then passes it on to the, Hidden
server. Ho= wever, the Hidden server responds with its own ServerHello
which = the Gateway just passes unchanged, because it's actually the
= response to ClientHello#2 rather than to ClientHello#1. As long as
ClientHello#1 and ClientHello#2 are similar (e.g., differing only in
the client's actual share (though of course it must be in the sam= e
group)), SNI, and maybe EarlyDataIndication), then an attacker = should
not be able to distinguish these cases.


Notes on several obvious technical issues:
=
1. How does the Gateway distinguish this case from where the= initial
=C2=A0 =C2=A0flight is actual application data? See belo= w for some thoughts
=C2=A0 =C2=A0on this.
=C2=A0 =C2=A0=
2. Can we make this work with 0-RTT data from the client to the = Hidden
=C2=A0 =C2=A0server? I believe the answer here is "ye= s", because the server's
=C2=A0 =C2=A0EarlyDataIndicatio= n does not carry the configuration_id. I just
=C2=A0 =C2=A0didn&#= 39;t show it in the diagram because it was already getting
=C2=A0= =C2=A0complicated.

3. What happens if the Gateway= server doesn't gateway, e.g., because
=C2=A0 =C2=A0it has fo= rgotten the ServerConfiguration? In that case, the
=C2=A0 =C2=A0c= lient gets a handshake with the Gateway, which it will have
=C2= =A0 =C2=A0to determine via trial decryption. At this point the Gateway
=C2=A0 =C2=A0supplies a ServerConfiguration and the client can reconn= ect
=C2=A0 =C2=A0as above.

4. What happe= ns if the client does 0-RTT inside 0-RTT (as in #2 above)
=C2=A0 = =C2=A0and the Hidden server doesn't recognize the ServerConfiguration i= n
=C2=A0 =C2=A0ClientHello#2? In this case, the client gets a 0-R= TT rejection and
=C2=A0 =C2=A0it needs to do trial decryption to = know whether the rejection was
=C2=A0 =C2=A0from the Gateway or t= he Hidden server.
=C2=A0 =C2=A0

The big = advantage of this design compared to the designs we were
discussi= ng in Yokohama is that it requires effectively no changes
to TLS.= The only thing you need is a way to signal to the Gateway
server= that the encrypted application data is actually a ClientHello
wh= ich is intended for the hidden service. The two most obvious
desi= gns are:

- Have an EncryptedExtension which indica= tes that the inner
=C2=A0 data is tunnelled.
- Have a &= quot;tunnelled" TLS content type.

In the inte= rest of explicit signaling I think EncryptedExtensions is
best bu= t we either need to require that all TLS 1.3 implementations
hand= le that extension or *also* have a new content type, because
othe= rwise it might be possible for an attacker to craft an inner
Clie= ntHello which was processable in part as an upper-level protocol
= message, which could be bad.

The major disadvantag= e of this overall design strategy (however it's
signaled) is = that it's somewhat harder to implement in the co-tenanted
cas= es than the most trivial "RealSNI" scheme. That means that it'= ;s
somewhat less likely that servers will implement it "by d= efault" and
more likely that they will have to take explicit= effort to allow
Encrypted SNI. Conversely, however, these modes = (aside from a server
with a single wildcard or multi-SAN cert) in= volve more changes to TLS
to deal with issues like "what is = the server cert that is digested
into the keys", and that re= quires more analysis, so there is an
advantage to deferring that.= If we have EncryptedExtensions in the
client's first flight = it would be possible to add RealSNI later
if/when we had clearer = analysis for that case.

Important note: this whole= discussion punts the question of how
a client knows that it can = do any of this stuff. My assumption
here is that the client learn= s it from the Hidden server in some
unprotected connection or via= some side channel (e.g., DNS).

-Ekr

[0] We need to do this anyway because we need to= have stuff like
"this is the ALPN for this first flight&quo= t;.




<= br>




<= br>

--001a11409380f4797505262ad9b9-- From nobody Sat Dec 5 11:15:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DD81A878C for ; Sat, 5 Dec 2015 11:15:09 -0800 (PST) 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_22=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 1BOUOJQSvwfu for ; Sat, 5 Dec 2015 11:15:08 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE201A0041 for ; Sat, 5 Dec 2015 11:15:07 -0800 (PST) Received: by ykdr82 with SMTP id r82so156671332ykd.3 for ; Sat, 05 Dec 2015 11:15:07 -0800 (PST) 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=ubq83MINVUtks+BTChKLmoEflov6GXz9UesPYvyI57A=; b=aH/fNbEpDuEQCxMZ/lDHgk/UGcLcllRhoizUqrxvjbLbLav+LKRF7VX8BL/+U6M5+6 QhIsCmryIn8fVDI+c44k7E3EIqn4Ra8uRwMXpyfHrMa08A8EtrhJlzgwOZ/8Wh87/QNh ytLMtYdeKaZE4osBSt/ALyiK2SjZvxjPZMuq6skgCLxb59ahAaf7Zy7ha4Z1q/wyohxY SQvMm0oxG0Gsvv3Ua3iozBELLVep/8d+D3ZfzCla7UMS1/LqElxELXVTNIw58vpCgM0Y Any9ngjk2q64gkME+bV8mPwsVYXRdeRcfaGB0uRZEUtwudz99OJWHYHRC21qfnm8cpYB fLkw== MIME-Version: 1.0 X-Received: by 10.129.57.135 with SMTP id g129mr15082394ywa.244.1449342907128; Sat, 05 Dec 2015 11:15:07 -0800 (PST) Received: by 10.129.148.131 with HTTP; Sat, 5 Dec 2015 11:15:07 -0800 (PST) In-Reply-To: References: Date: Sat, 5 Dec 2015 14:15:07 -0500 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2015 19:15:09 -0000 On Sat, Dec 5, 2015 at 1:32 PM, Eric Rescorla wrote: > Subject: SNI Encryption Part XLVIII > > Folks, > > TL;DR. > This message describes a technique for doing SNI encryption that just > requires (re)adding EncryptedExtensions to the client's first flight [0] > defining an extension that indicates "tunnelled TLS" and (maybe) a new > TLS content type. We would only tunnel the first flight and everything > else would be handed off to the hidden service. This seems like the > minimal change to enable Encrypted SNI while retaining our existing > analytical frame for the rest of TLS. > > > DETAILS > During the discussion of SNI Encryption in Yokohama, Deb Cooley > argued that rather than messing with TLS to allow SNI encryption, > we should just tunnel TLS in TLS. A number of people objected > to this on the grounds of the performance cost for the gateway > because it has to encrypt and decrypt everything. > > After the meeting, Martin Thomson suggested a modification to the > tunnelling proposal that removes this cost. The key observation is > that if we think of the 0-RTT flight as a separate message attached to > the handshake, then we can tunnel a second first flight in it. Here's > the idea: > > Client Gateway Hidden > > ClientHello#1 > + KeyShare > + EarlyDataIndication > + SNI = gateway > (Finished) > ( > ClientHello#2 > + KeyShare > + SNI = hidden > // > ) > (end_of_early_data alert) ----> > > ClientHello#2 > + KeyShare > + SNI = hidden > ----> > ServerHello > + KeyShare > {EncryptedExtensions} > {ServerConfiguration*} > {Certificate*} > {CertificateRequest*} > {CertificateVerify*} > <------------------------------- {Finished} > {Finished} -------------------------------> > > > Key to brackets: > > () encrypted with Client->Gateway 0-RTT key (either handshake or data) > <> encrypted with Client->Hidden 0-RTT key > {} encrypted with Client->Hidden 1-RTT handshake > > > The way this works is that the Gateway decrypts the *data* in the > client's first flight, which is actually ClientHello#2 from the > client, containing the true SNI and then passes it on to the, Hidden > server. However, the Hidden server responds with its own ServerHello > which the Gateway just passes unchanged, because it's actually the > response to ClientHello#2 rather than to ClientHello#1. As long as > ClientHello#1 and ClientHello#2 are similar (e.g., differing only in > the client's actual share (though of course it must be in the same > group)), SNI, and maybe EarlyDataIndication), then an attacker should > not be able to distinguish these cases. > > > Notes on several obvious technical issues: > > 1. How does the Gateway distinguish this case from where the initial > flight is actual application data? See below for some thoughts > on this. > > 2. Can we make this work with 0-RTT data from the client to the Hidden > server? I believe the answer here is "yes", because the server's > EarlyDataIndication does not carry the configuration_id. I just > didn't show it in the diagram because it was already getting > complicated. > > 3. What happens if the Gateway server doesn't gateway, e.g., because > it has forgotten the ServerConfiguration? In that case, the > client gets a handshake with the Gateway, which it will have > to determine via trial decryption. At this point the Gateway > supplies a ServerConfiguration and the client can reconnect > as above. > > 4. What happens if the client does 0-RTT inside 0-RTT (as in #2 above) > and the Hidden server doesn't recognize the ServerConfiguration in > ClientHello#2? In this case, the client gets a 0-RTT rejection and > it needs to do trial decryption to know whether the rejection was > from the Gateway or the Hidden server. I've got another question: how does the client know that the gateway is supposed to be the gateway? As it stands it seems an attacker can MITM the Gateway, and recover all SNIs. Sincerely, Watson From nobody Sat Dec 5 11:31:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729471A8A89 for ; Sat, 5 Dec 2015 11:31:02 -0800 (PST) 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 ORGrftmneqWE for ; Sat, 5 Dec 2015 11:31:01 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 313081A8A8A for ; Sat, 5 Dec 2015 11:31:01 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0DE34284E32; Sat, 5 Dec 2015 19:31:00 +0000 (UTC) Date: Sat, 5 Dec 2015 19:31:00 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151205193059.GI18315@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.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Encrypted SNI 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: Sat, 05 Dec 2015 19:31:02 -0000 On Sat, Dec 05, 2015 at 02:15:07PM -0500, Watson Ladd wrote: > I've got another question: how does the client know that the gateway > is supposed to be the gateway? As it stands it seems an attacker can > MITM the Gateway, and recover all SNIs. That's a whole lot different than passively reading all the SNIs, if not this or similar, then we're sending the SNI in the clear... That said, ekr's post includes: Important note: this whole discussion punts the question of how a client knows that it can do any of this stuff. My assumption here is that the client learns it from the Hidden server in some unprotected connection or via some side channel (e.g., DNS). DNS seems to make sense, because in any case the client will already be asking for the IP address of the same said server via DNS. It may as well ask for the 0-RTT key. If DNS is in the clear for the IP address, then encrypting SNI is often (absent TOR and the like) pointless, if DNS is protected then the key lookup is also protected. -- Viktor. From nobody Sat Dec 5 12:53:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546901A1B5F for ; Sat, 5 Dec 2015 12:53:57 -0800 (PST) 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_22=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 hckHlJdXMhC7 for ; Sat, 5 Dec 2015 12:53:55 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548271A1B4B for ; Sat, 5 Dec 2015 12:53:55 -0800 (PST) Received: by qgec40 with SMTP id c40so116351049qge.2 for ; Sat, 05 Dec 2015 12:53:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=JGBsGg+eRgzTo38gAfoQtzVzuyG/OHLx1EANH9DL9/8=; b=CcX5aZ1tk2ky3FDw5S7+SvUHW7SbKGo0p3Ldo/oD+jTxnPxQULriX7vdeFlPZuvNqL jvBJUkp8igTqjafZrmUS0umqNdM71TkUvvVLhezNed7y+V7X/Xl2qbm7nE9GKk3tJOa0 EwnI28kFPK3KN7opNMybHSu1L2IBnCI4iXqUCgq1jyt9Yk9G/ouJJwLKIfnFyXkU6HEB IpTK7bAIt7jUKuj1EjCEivg6LLnWQXBm20AQCEBfmGHPHuPgugDprDna2tLniO7zjihA 6yE5v85zNp4CpOokTSz/AHd1TVsBAdThh+iEwTm+INhE0mJBm4xPpPJC/b9Bu+YtMWfW FufQ== X-Received: by 10.140.166.10 with SMTP id m10mr27716796qhm.35.1449348834590; Sat, 05 Dec 2015 12:53:54 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id p17sm8251913qhb.34.2015.12.05.12.53.54 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 05 Dec 2015 12:53:54 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Sat, 5 Dec 2015 15:53:52 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201512051553.53074.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2015 20:53:57 -0000 On Saturday, December 05, 2015 01:32:11 pm Eric Rescorla wrote: > Subject: SNI Encryption Part XLVIII > > Folks, > > TL;DR. > This message describes a technique for doing SNI encryption that just > requires (re)adding EncryptedExtensions to the client's first flight [0] > defining an extension that indicates "tunnelled TLS" and (maybe) a new > TLS content type. We would only tunnel the first flight and everything > else would be handed off to the hidden service. This seems like the > minimal change to enable Encrypted SNI while retaining our existing > analytical frame for the rest of TLS. [...snip...] Neat. This design is modeled more similarly to what SNI is actually for and this generalized approach may be useful for other applications. Not that simple, but we knew that we weren't going to get that here. This is actually more than just SNI encryption; every possible indicator in a server's first flight gets encrypted here. We can get encrypted ALPN through this too, which could be nice to have. It would give ideal protection against attempts to identify the intended server via ClientHello fingerprinting, in general. (still a finite amount of virtual hosts to guess from, but that's not fixable here) Sounds like a good proposal to me. :) Dave From nobody Sat Dec 5 14:26:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383F01A90BE for ; Sat, 5 Dec 2015 14:26:31 -0800 (PST) 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 oNti0t_SN-dq for ; Sat, 5 Dec 2015 14:26:30 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A0F1A90BD for ; Sat, 5 Dec 2015 14:26:29 -0800 (PST) Received: by wmww144 with SMTP id w144so106641302wmw.0 for ; Sat, 05 Dec 2015 14:26:28 -0800 (PST) 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=2qVaAYpMgbLaBKwVSyRODG5BeAGwDKX/scuM84Cogtg=; b=n7C2D6izEQJMDW+sWqGfD4eUFRMVSHbczGvIjovGSUCHWJ1imXpjoYLuPqFucoCLfm F+Q/xat43nyvLJB44Z/v5hOOTL94HIWyXCC1cJ+enhC11ge5sZYcZ/RFu9u4Mt3GIKgW 7+HpEt1WG+TV5lRNZMq968avXCtuomNlqtkDq8vOSwKXSjtOa1n6PwQ60ykGlflyj1hr fstkiRC+NASVmfG0uaW7p4/eKI6fVV5cwHMEPQBCJLuWUYSuK8ezKWUgzRfb/fe35gRV DTZrIdnSOUfAsbg2Y7ypyVrdJpMohCRlxgaxwc8MAQ0WsSkEh6m+eJahNhEfn5ty1rJh KQoQ== X-Received: by 10.194.78.212 with SMTP id d20mr26810773wjx.70.1449354388365; Sat, 05 Dec 2015 14:26:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.33.138 with HTTP; Sat, 5 Dec 2015 14:25:48 -0800 (PST) From: Ryan Carboni Date: Sat, 5 Dec 2015 14:25:48 -0800 Message-ID: To: "tls@ietf.org" , jacob@appelbaum.net, "Salz, Rich" Content-Type: multipart/alternative; boundary=047d7bfcefb078e6df05262e1db5 Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2015 22:26:31 -0000 --047d7bfcefb078e6df05262e1db5 Content-Type: text/plain; charset=UTF-8 > > If Akamai wants to leave their users insecure, I look forward to > another CDN offering privacy options. Such choice is missing if that > isn't an option and it isn't on as a strong default. The NSA has contracts with ISPs to have access to their user's content. Is a CDN an ISP? --047d7bfcefb078e6df05262e1db5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If Akama= i wants to leave their users insecure, I look forward to
another CDN offering pr= ivacy options. Such choice is missing if that
isn't an option and it isn'= ;t on as a strong default.

The NSA h= as contracts with ISPs to have access to their user's content.

Is a CDN an ISP?
--047d7bfcefb078e6df05262e1db5-- From nobody Sat Dec 5 14:40:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7D61A90F3 for ; Sat, 5 Dec 2015 14:40:24 -0800 (PST) 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] 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 ysybtAzhQ0s2 for ; Sat, 5 Dec 2015 14:40:23 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3541A90E9 for ; Sat, 5 Dec 2015 14:40:23 -0800 (PST) Received: by ioc74 with SMTP id 74so149075620ioc.2 for ; Sat, 05 Dec 2015 14:40:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3wJrDoLCywIT/Edfy9k6Tw0peVNLPmPrIsx+P+kJ+gs=; b=o2dgFV/j4PmqQ6oVWvPS8nZzYAHCHjB5RdnqO+9aUpZcMU4Vep6XRfvjZIUkbcaPNy jCbaOECGd6ABKV9aqrYLMCfRxIEIx6hR3KyI7/ByHpODcNhxDpQb3ttCjkDm81xN9eN+ ChivU58kD32GoFLRDuMUEIT8X3AQDj+e7yANrcP41t5OyBDzF7nh7YcPCLkgwA9+9hB6 7Y0BZHoH25XK3vsSabsMMnl9tdauejBC2w9rD+6vfUQP4NL8lD88f85hKcKOXfZMVPHE 0l+30LncBi2nzPaU/N96UsQklppzQlmhWFgf+Fiwq1zdkKi1Z3XMgRu1Ia/BTvCdq5iE utaA== 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=3wJrDoLCywIT/Edfy9k6Tw0peVNLPmPrIsx+P+kJ+gs=; b=jUxGnVTgl6RYPiqTuzMSrpNvAEZrl2zUNnovIGdt0hA/2E9+p82U6ORj/og0QO0DyL r630DQlgbPwy0H+KVPQ3TYHMXyrlJbf+G0jms6PJ+AxtTOKNZ0GLzmZYc/Z7dW/eafvb DfFu8jbd1lf8QwhaduWFFEVQvUf7eBugq1GefJV2e0pkRdF65CnXFPmUCIcIFuhNaJL4 u4pCLu+9kpeZEHyToFg3qJpnTW2Nk85zvCcOCGWkNRDkrgMM8iMmVaSx4ijb5sIG3Xbb +NpkYuFVoDKUv/Lly/UwB54jde0OY2KdFs3M3svU9lcmhB4r57LsqUMocn+qZzTl/1i5 zfeg== X-Gm-Message-State: ALoCoQm2m8vce3rfEvCBhIMTSWjepBuZxZhbHrWCK6xnoFeWR4+c+WHSoT7BrCIjRs5IBqxVervJ MIME-Version: 1.0 X-Received: by 10.107.137.19 with SMTP id l19mr17752576iod.138.1449355222908; Sat, 05 Dec 2015 14:40:22 -0800 (PST) Received: by 10.79.70.71 with HTTP; Sat, 5 Dec 2015 14:40:22 -0800 (PST) X-Originating-IP: [94.242.246.24] In-Reply-To: References: Date: Sat, 5 Dec 2015 22:40:22 +0000 Message-ID: From: Jacob Appelbaum To: Ryan Carboni Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2015 22:40:24 -0000 On 12/5/15, Ryan Carboni wrote: >> >> If Akamai wants to leave their users insecure, I look forward to >> another CDN offering privacy options. Such choice is missing if that >> isn't an option and it isn't on as a strong default. > > > The NSA has contracts with ISPs to have access to their user's content. > Which did you have in mind? AT&T? Sure. And for unilateral access they do it without contracts such as the TAT cable. > Is a CDN an ISP? > Are you asking if the CDN gives data to the NSA, I guess you'd just have to ask them directly. I guess they won't answer or they'll be legally obliged to lie. All the best, Jacob From nobody Sat Dec 5 15:54:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EBA1AC437 for ; Sat, 5 Dec 2015 15:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 7UK9qZ9y-8le for ; Sat, 5 Dec 2015 15:54:30 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 930171AC434 for ; Sat, 5 Dec 2015 15:54:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1449359669; x=1480895669; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Acn+ssWrXNRZILjnNN4VGmfFheWw/ZzgreBv4exOMbY=; b=2AJRpgiN2A/a6XKxRr4XACnPtu+j4DKsogM1ZLI6lUQYnStJN8CDCHOw 8UwS89ya3heXflDPkygZG4bp06gvx0mCdd/nvxnM5iELncCCfYOu9u4qZ sFbgQ5vLtoTpSgcdQfd6plBulN+CTBzZx4Q/T3FdFg6dRCX8MfazVeEgb yLXFr5DsFtGtizwK8g8fxmCmbDBuSyRWlbwNPfMxLrllJi5EUig7dfLGp xBHyuoS6Aq6BwgVS83zfUDMEhSt57C2KiiPpCFMlpGpcHjVFGD4Ymr6ev yDhy87NOGplz/rUPa+pOGl8vGqksldw4YsfsComt3CRGVZrLAEJ8Ry9iT Q==; X-IronPort-AV: E=Sophos;i="5.20,387,1444647600"; d="scan'208";a="57771887" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe2.UoA.auckland.ac.nz) ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Dec 2015 12:54:26 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Sun, 6 Dec 2015 12:54:26 +1300 From: Peter Gutmann To: Hubert Kario , Kurt Roeckx Thread-Topic: [TLS] Fwd: Clarification on interleaving app data and handshake records Thread-Index: AQHRLruiXKcfeysJmkanva71LFEja569EsIx Date: Sat, 5 Dec 2015 23:54:25 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B9B3DA@uxcn10-5.UoA.auckland.ac.nz> References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <2977428.j4DNTR9LXR@pintsize.usersys.redhat.com> <20151016203610.GA5596@roeckx.be>, <2348468.lpGyMim7ub@pintsize.usersys.redhat.com> In-Reply-To: <2348468.lpGyMim7ub@pintsize.usersys.redhat.com> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Dec 2015 23:54:32 -0000 Hubert Kario writes:=0A= =0A= >miTLS does accept Application Data when it is send between Client Hello an= d=0A= >Client Key Exchange and rejects it when it is sent between Change Cipher S= pec=0A= >and Finished.=0A= =0A= Given that miTLS is a formally verified implementation, would this imply th= at=0A= there's a problem with the verification? "Beware of bugs in the above code= ; I=0A= have only proved it correct, not tried it"?=0A= =0A= Peter.=0A= From nobody Sat Dec 5 16:01:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F194C1ACD04 for ; Sat, 5 Dec 2015 16:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 J7sKsUV2SwAV for ; Sat, 5 Dec 2015 16:01:12 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8438E1ACCFA for ; Sat, 5 Dec 2015 16:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1449360071; x=1480896071; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4CCyBjQGhX+CYcoKDwq6qr3BcoP21VO7RDw987ad5bk=; b=ITGOXCsDJlxzp7ZPcLqA61LUiylEykjdfBiU0mVnnS5EYQ4zxaylm8S4 KWK4eenIM0Jrx3EmJjBeFqqdnwlGYgDOSu4XJUdwkIpHOe0/9AcRm3Xz8 VGpQr+aKVwjZbEqqvEl9TLyXQhjjm7ctcAz115xQJsp+6k9WEGMmbeX4z Pm2soXiLWI7f0eGvZrBw/ep3c3GEnllAoA9taQq03WE06vmFIw8awm/T5 Jyx6FROnazr/tTpQXGqKL8ws8ZHDTS2nu/eYsw+spI5hA2958eCkQqdGq ZzQZ4VF19XRVU+miYAANsavH28MKtS2/KnutgwmdxK6n1boAZiEAgPQPw A==; X-IronPort-AV: E=Sophos;i="5.20,387,1444647600"; d="scan'208";a="57772239" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe3.UoA.auckland.ac.nz) ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Dec 2015 13:01:10 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Sun, 6 Dec 2015 13:01:10 +1300 From: Peter Gutmann To: Jacob Appelbaum Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all? Thread-Index: AQHRLkbyDcSlq8FU5UOLue9+6obNgZ69FcGl Date: Sun, 6 Dec 2015 00:01:09 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B9B407@uxcn10-5.UoA.auckland.ac.nz> References: <20151203165344.C639C1A3A0@ld9781.wdf.sap.corp> <9A043F3CF02CD34C8E74AC1594475C73F4B9865A@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 00:01:13 -0000 Jacob Appelbaum writes:=0A= =0A= >On 12/4/15, Peter Gutmann wrote:=0A= >> Jacob Appelbaum writes:=0A= >>>TCP/IP and DNS are out of scope, though obviously related.=0A= >> Why are they out of scope?=0A= >=0A= >They are out of scope for the TLS working group as far as I understand the= =0A= >organization of the IETF in terms of mandate. Am I incorrect?=0A= =0A= They're out of scope in that TLS can't impose behaviour on DNS, but they're= =0A= not out of scope when it comes to considering what impact DNS has on TLS. = For=0A= example the whole reason why TLS has certificates is because the TLS (well,= =0A= SSL then) folks realised that DNS wasn't secure, and that TLS had to deal w= ith=0A= that issue. Otherwise, the SSL folks could have just said that DNS issues = are=0A= out of scope, and we'll wait for DNSSEC to appear at some point and fix thi= ngs=0A= (this is speaking from a 1995 time frame).=0A= =0A= >Or they could just call MinimaLT or CurveCP with mandatory Elligator TLS 1= .3=0A= >and be done with it.=0A= =0A= That would probably be an easier process than the current one, provided you= 're=0A= ready to commit completely to the Bernstein monoculture.=0A= =0A= Peter.= From nobody Sat Dec 5 16:20:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B664E1B2D9F for ; Sat, 5 Dec 2015 16:20:14 -0800 (PST) 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 S639jqyi7z1V for ; Sat, 5 Dec 2015 16:20:12 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68AD51ACD1D for ; Sat, 5 Dec 2015 16:20:12 -0800 (PST) Received: by ykdv3 with SMTP id v3so160725223ykd.0 for ; Sat, 05 Dec 2015 16:20:11 -0800 (PST) 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=ILa0Mzk76Hnik5SXzD5x0aBk/o2syQjItoZsKzDKxCc=; b=eZ3kw1Nd4xmF0avZGgP7rVx5bzdsseRjKIWbz3hdV9HDB8WhSco0L2Wi7Az9jSVOjv +3jDGW/EsUk/ExM2S8Gbkoj6t33+N/zRhOvYi0GYX1IXFAsXMk7K617QKBTSkVHzMewY Qk8TfJLOWpgYgpceeF0nwbx9Em+FOZtq5cg1FBiWz9gSME839sdoXsmcSQaPFvg83AUe EkJIKLHEPdg6+7PxVCusG31hId9OJEmXlD9Ubv22FGI3yXhb5s/7aanATiNIIKDs57y5 ht5OHgNnuwowUg3/l8B/7qwKOiwQUseCU+YwZ4Wh1cQp1vYikq3ysiQntgl6oJ8BjHo0 T3kQ== MIME-Version: 1.0 X-Received: by 10.13.193.6 with SMTP id c6mr17407388ywd.326.1449361211513; Sat, 05 Dec 2015 16:20:11 -0800 (PST) Received: by 10.129.148.131 with HTTP; Sat, 5 Dec 2015 16:20:11 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B9B3DA@uxcn10-5.UoA.auckland.ac.nz> References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <2977428.j4DNTR9LXR@pintsize.usersys.redhat.com> <20151016203610.GA5596@roeckx.be> <2348468.lpGyMim7ub@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B3DA@uxcn10-5.UoA.auckland.ac.nz> Date: Sat, 5 Dec 2015 19:20:11 -0500 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 00:20:14 -0000 On Sat, Dec 5, 2015 at 6:54 PM, Peter Gutmann wrote: > Hubert Kario writes: > >>miTLS does accept Application Data when it is send between Client Hello and >>Client Key Exchange and rejects it when it is sent between Change Cipher Spec >>and Finished. > > Given that miTLS is a formally verified implementation, would this imply that > there's a problem with the verification? "Beware of bugs in the above code; I > have only proved it correct, not tried it"? Are you saying there is a security flaw with the behavior described? Because I don't believe there is after one adopts Extended Master Secret. (Someone more familiar with the security should check this) > > Peter. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sat Dec 5 16:24:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5196C1B2DBC for ; Sat, 5 Dec 2015 16:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, T_RP_MATCHES_RCVD=-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 s6kTklgRU140 for ; Sat, 5 Dec 2015 16:24:50 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522D31B2D96 for ; Sat, 5 Dec 2015 16:24:50 -0800 (PST) Received: by igl9 with SMTP id 9so54746038igl.0 for ; Sat, 05 Dec 2015 16:24:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Lbvwiu5SWVghCDlASoi4wi3UhdyseLNh/Zp7VKQcgMo=; b=crRRpf0Fi/XzrrkhXUB5ryltcuBuMffNZMrGr9DaGOamNDCUYULy2AjNOktcZUuAxu eX474Ko1yDgOtwr6p8hLk6tJ6DC17w3mi1gT48FsJgKlW5EaMATPlfVPyJn/jJXvrsxy JUdMktNDfNij3L5I87m+/e7d9M1K2AuwudSa4g6uLzjRPbWPIxL0ZwRwafyVeiWSRntD ax9PVANHEQNEJIIC8R93vamK3bQ31sbqHb1ljLxI+uCg4B9m2w9FMNGf6J11ZNQOmeyZ mJls/94AEa6IzLz92c9070d6S6C+NLpJiP3nkY9t3XQllnmZa3b4enAQ6pezPNc4gd/3 YAww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Lbvwiu5SWVghCDlASoi4wi3UhdyseLNh/Zp7VKQcgMo=; b=No4RI4VYPuO0xIt2joEt+0eiiBnTcJoD17yXpiIYYgLAezXi7PrtRO0qFOU5SM8smm FpO0O++9k/E0VLEEuKyt6p2XIl1Cj5MlaKippRYhAbmdfUwcuxRwPDyCaX0498AIZ72T KLRZvT/Xhm35SUrzTYwwnFTKvT6xq8Y98zY2X8sP9mB5it7LVed7DbVMZ6j4de6uZO7v dupLjI9XWZ4oKzyf/EWGVj7S6tvEVEu/Mr5QjIkq95od4rTqlN4fVwt9P9AUeJnDgLGt oAtYkNfcw4UmBx011QYw6McfhVrkybQC7rnuxesNJs+xdBWluHpbivvk75HgChf7JuLC 9Gag== X-Gm-Message-State: ALoCoQkdcQzX2AFeHv3d9VmEuHidRrpMvnvVo5Rt+BlShIFPZh1kIAS/395FMlkmcBXYD0zc1rG9 MIME-Version: 1.0 X-Received: by 10.50.150.9 with SMTP id ue9mr10508455igb.40.1449361489533; Sat, 05 Dec 2015 16:24:49 -0800 (PST) Received: by 10.107.173.15 with HTTP; Sat, 5 Dec 2015 16:24:49 -0800 (PST) Date: Sat, 5 Dec 2015 16:24:49 -0800 Message-ID: From: Bill Cox To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113491a4bc68a505262fc4ea Archived-At: Subject: [TLS] Would there be security issues with a 0-RTT resume? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 00:24:51 -0000 --001a113491a4bc68a505262fc4ea Content-Type: text/plain; charset=UTF-8 I am not sure why we have a 0-RTT connect, but only a 1-RTT resume. If anything, it seems like it would be easier to have a secure 0-RTT resume than a 0-RTT connect, though the 0-RTT connect does use some information from prior connections. Is there a good reason for having only a 0-RTT connect, and not resume? Thanks, Bill --001a113491a4bc68a505262fc4ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am not sure why we have a 0-RTT connect, but only a 1-RT= T resume.=C2=A0 If anything, it seems like it would be easier to have a sec= ure 0-RTT resume than a 0-RTT connect, though the 0-RTT connect does use so= me information from prior connections.

Is there a good r= eason for having only a 0-RTT connect, and not resume?

T= hanks,
Bill
--001a113491a4bc68a505262fc4ea-- From nobody Sat Dec 5 16:47:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFF61ACE01 for ; Sat, 5 Dec 2015 16:47:41 -0800 (PST) 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, HTML_MESSAGE=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 VqOtYupkJxeS for ; Sat, 5 Dec 2015 16:47:40 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6701ACDEE for ; Sat, 5 Dec 2015 16:47:40 -0800 (PST) Received: by ykdv3 with SMTP id v3so161029644ykd.0 for ; Sat, 05 Dec 2015 16:47:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9CRk3XupC5O1bRbQI2yQHYpM3Ygq9Np/lHYqPTmGkCw=; b=G/1Vrps+LeaeZgVGTt4PLHST4H/4kzU7L4lF5GSANZQgfPc8BRJkwgQLX7MduEXKue CpQWIbYXcwxb1jbvpgvhzNQAhl87nGjH6pKfbcUrIwAqRjppEyYGde7i8ELNEX0ILeeD IUlxyg/7cto2ezWlbxAj8takfYDSzdGdHCUKKVk6q7QyyplRo9yUH6VIcbTNzkv2Kq/O MLXcT7/los148/b96aXA1YgvnokXg59QDm85pp2g7HM2bbYEJtfKg72RcnV7IhwteoA+ 7n3lRO4Tj5fwPoE/8FZvfDH47UrcWl+FFVzNwDMLBSg//E3n+H1cvHdnEV3iAcKidODE inRQ== 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=9CRk3XupC5O1bRbQI2yQHYpM3Ygq9Np/lHYqPTmGkCw=; b=N6nXhusxuQgWQMlBS3kr0W/CGErJhG4LcAmcTAA5ofhQ+Is6C8EXzxsZjAKLw7IXsx 2q7vDiylFi/f+9mHkoJiDmxblHBwplPOe9UeRBUah16/GpS400APbAKhL2v6MH6/IcMQ O40if2eLUIqsk3zvjjxNJ4XMDW548Y8wQQ2CYFk1nlZKcWq5RuTFAa6bPA13kxOP/NZM SqccreOyd91i9ff8slw0jLgwbr4hn1+TYqIuFf/Y+NhKsaoccDyyRzeiiay1CJnQYBKa 9usk7lhE5VtdJY4iKuNbFx7UDF/jrqfm+bGKUCh18SOclDNdocKEYl+4nkXGVC7OyQ3o hB+A== X-Gm-Message-State: ALoCoQkyCEWF+0NYKR432GttDROWqyF88XWb15p6cuDlAnVhUyO6aoPkbhVV7TDAbQ6bvxOHkx6e X-Received: by 10.129.73.198 with SMTP id w189mr18869687ywa.223.1449362859317; Sat, 05 Dec 2015 16:47:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Sat, 5 Dec 2015 16:46:59 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sat, 5 Dec 2015 16:46:59 -0800 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a114dc814618e37052630161d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Would there be security issues with a 0-RTT resume? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 00:47:41 -0000 --001a114dc814618e37052630161d Content-Type: text/plain; charset=UTF-8 On Sat, Dec 5, 2015 at 4:24 PM, Bill Cox wrote: > I am not sure why we have a 0-RTT connect, but only a 1-RTT resume. If > anything, it seems like it would be easier to have a secure 0-RTT resume > than a 0-RTT connect, though the 0-RTT connect does use some information > from prior connections. > > Is there a good reason for having only a 0-RTT connect, and not resume? > The intention *is* to have a 0-RTT resume, since PSK and 0-RTT should be compatible. The spec may not be entirely clear on this point, though. -Ekr Thanks, > Bill > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114dc814618e37052630161d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Dec 5, 2015 at 4:24 PM, Bill Cox <waywardgeek@google.com= > wrote:
I= am not sure why we have a 0-RTT connect, but only a 1-RTT resume.=C2=A0 If= anything, it seems like it would be easier to have a secure 0-RTT resume t= han a 0-RTT connect, though the 0-RTT connect does use some information fro= m prior connections.

Is there a good reason for having o= nly a 0-RTT connect, and not resume?

The intention *is* to have a 0-RTT resume, since PSK and 0-RTT should= be
compatible. The spec may not be entirely clear on this point,= though.

-Ekr

Thanks,
Bill

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


--001a114dc814618e37052630161d-- From nobody Sat Dec 5 17:18:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF201B2DF6 for ; Sat, 5 Dec 2015 17:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 yv4kXotUoCIa for ; Sat, 5 Dec 2015 17:18:57 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96D0D1B2DF2 for ; Sat, 5 Dec 2015 17:18:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1449364737; x=1480900737; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2zKt1bFmGtbO14pAxzu9G4qyfn7IsoQ+DkEF0FCoX1w=; b=mqwIgvCS3WRUajA25s7masXSijwX4Pt3Lndn9ROKeOhb3zRecqrUSKfO zQvpJLCOfwMY//9WPMU/JSKwnvxgDoKU5C1DutzMpH7ZebIFM7s0i/9dC D3kov/VJNgZtY6yMrkINGJO5yAnjHZmOCpv565LMRzTjzfHDh9abNRMPM PWm9FOKZaEAPWNVnynhcjVEsURcRZ9Wd93JM9JyOWIo6YvsYfffaE1BEG h1h8HmHYskcUAzIcMvsm/71w/aUJB+Pn7zOxzHCYogbdH0kGDdpe9SFd5 TqH45XLAjboHmpPZcIP7TAfNLt9hdVT+BSet8u+r1/bq49B/Ic5mauz2s Q==; X-IronPort-AV: E=Sophos;i="5.20,387,1444647600"; d="scan'208";a="57775777" 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 mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Dec 2015 14:18:53 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Sun, 6 Dec 2015 14:18:53 +1300 From: Peter Gutmann To: Watson Ladd Thread-Topic: [TLS] Fwd: Clarification on interleaving app data and handshake records Thread-Index: AQHRLruiXKcfeysJmkanva71LFEja569EsIx//8tlYCAAOk3KQ== Date: Sun, 6 Dec 2015 01:18:51 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B9B509@uxcn10-5.UoA.auckland.ac.nz> References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <2977428.j4DNTR9LXR@pintsize.usersys.redhat.com> <20151016203610.GA5596@roeckx.be> <2348468.lpGyMim7ub@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B3DA@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 01:18:58 -0000 Watson Ladd writes:=0A= >On Sat, Dec 5, 2015 at 6:54 PM, Peter Gutmann = wrote:=0A= >> Hubert Kario writes:=0A= >>=0A= >>>miTLS does accept Application Data when it is send between Client Hello = and=0A= >>>Client Key Exchange and rejects it when it is sent between Change Cipher= Spec=0A= >>>and Finished.=0A= >>=0A= >> Given that miTLS is a formally verified implementation, would this imply= that=0A= >> there's a problem with the verification? "Beware of bugs in the above c= ode; I=0A= >> have only proved it correct, not tried it"?=0A= >=0A= >Are you saying there is a security flaw with the behavior described?=0A= =0A= I hadn't even thought it through to that point, more that you're not suppos= ed=0A= to accept anything between Client Hello and Client Keyex except an optional= =0A= Client Certificate.=0A= =0A= (OK, I haven't gone through every extension RFC and draft to see what else = you=0A= could poke in there, but I'm pretty sure Application Data isn't one of them= ).=0A= =0A= Peter.=0A= From nobody Sat Dec 5 17:52:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B711B2E5C for ; Sat, 5 Dec 2015 17:52:50 -0800 (PST) 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] 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 NZXHDV5UuYZw for ; Sat, 5 Dec 2015 17:52:49 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8461B2E5D for ; Sat, 5 Dec 2015 17:52:46 -0800 (PST) Received: by iouu10 with SMTP id u10so154233582iou.0 for ; Sat, 05 Dec 2015 17:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hWlwl5ohTaJQrIn+E6b0/LtvqJnBtEIZm5pWD9bFuTg=; b=OHy3vtlAlIoB4bwG0f4cjpd9XCVJhBQZgumU/6E4iKWEMATBZTFVEqwVBY4769CEMZ m6HTpP75173taRGLQVSgxRG3TXQkVl9wSK6Q58bBQ9/RyYpEfqdgVkdjnDMBxhC/r0a0 rOYvx4RLb0tpFPdV6QOFVTNjgnP1Ucti8hCsr0D1ZppXETja6zdsFRwEOsE2J9iSe31P bVIKtd04zEoUSaFtTJTxGeym3fdxt4Id5bF3GO9svTGr4meQnDdKdgTVtOA/a8P0NFo3 YW5OLIQQ4odyip0BU9Hs4dXAFymUOnYJi9zqv+Dv/eEbr3pwujGCQNFiZd20+7C+1O2q 8zFg== 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=hWlwl5ohTaJQrIn+E6b0/LtvqJnBtEIZm5pWD9bFuTg=; b=AMb03mwS7HYVWywuohFdytOsYjQcida8nu3YNjtux2weOx4QYdHOICt4HgJQyQhggl jUZIMHRPb5YNyBvVhT532XrYs1w86v8yz74XbS1qErFDy09LI8Z2KJKTzjCp1lHhdCYJ iwKU4LXAFL8NcXDTkshK/5fjFjIOLKad3cktc07bZ+xRt+8dc9+2BCGhug+8vFSFOsfF QfpOqINvzSMNhlWU6PirBFuLEpNw40mJOIV/1OyfhYpmtD4aES6RS5wn+HSxfYXO8xxD WGhvRR4zKF9IzHUgRfNm2PjBHI3hP3BG9oJ+X3E8ORIa79p5FyfHBQZh4wMlRMpNEHwa lxSA== X-Gm-Message-State: ALoCoQkSZBeH9W0P7Fcv4cZuSkT1gHB9UJx0h7bOKK62cwHW5I/v8wVQ7bHBoxdJwxMtM2Szec1N MIME-Version: 1.0 X-Received: by 10.107.7.210 with SMTP id g79mr19914942ioi.81.1449366765459; Sat, 05 Dec 2015 17:52:45 -0800 (PST) Received: by 10.79.70.71 with HTTP; Sat, 5 Dec 2015 17:52:44 -0800 (PST) X-Originating-IP: [199.87.154.255] In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B9B407@uxcn10-5.UoA.auckland.ac.nz> References: <20151203165344.C639C1A3A0@ld9781.wdf.sap.corp> <9A043F3CF02CD34C8E74AC1594475C73F4B9865A@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9B407@uxcn10-5.UoA.auckland.ac.nz> Date: Sun, 6 Dec 2015 01:52:44 +0000 Message-ID: From: Jacob Appelbaum To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 01:52:50 -0000 On 12/6/15, Peter Gutmann wrote: > Jacob Appelbaum writes: > >>On 12/4/15, Peter Gutmann wrote: >>> Jacob Appelbaum writes: >>>>TCP/IP and DNS are out of scope, though obviously related. >>> Why are they out of scope? >> >>They are out of scope for the TLS working group as far as I understand the >>organization of the IETF in terms of mandate. Am I incorrect? > > They're out of scope in that TLS can't impose behaviour on DNS, but they're > not out of scope when it comes to considering what impact DNS has on TLS. Of course. Thankfully there is work to fix DNS by... using TLS! > For > example the whole reason why TLS has certificates is because the TLS (well, > SSL then) folks realised that DNS wasn't secure, and that TLS had to deal > with > that issue. Otherwise, the SSL folks could have just said that DNS issues > are > out of scope, and we'll wait for DNSSEC to appear at some point and fix > things > (this is speaking from a 1995 time frame). Hopefully someday, we'll have the DNS security problem solved. Until then, I look forward to the TLS working group to not making name privacy _harder_ to implement. The great irony of DNS potentially using TLS for privacy is... oh, so much for that strategy. >>Or they could just call MinimaLT or CurveCP with mandatory Elligator TLS >> 1.3 >>and be done with it. > > That would probably be an easier process than the current one, provided > you're > ready to commit completely to the Bernstein monoculture. I admit, I'm biased here. I'd rather have a monoculture of security than polyculture of insecurely designed by commitee. All the best, Jacob From nobody Sat Dec 5 17:59:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E2B1B2E85 for ; Sat, 5 Dec 2015 17:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 fzmezSoQTjg4 for ; Sat, 5 Dec 2015 17:59:00 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBFA1B2E7D for ; Sat, 5 Dec 2015 17:59:00 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 87A31425DB7; Sun, 6 Dec 2015 01:58:59 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 6C92A4F0D6; Sun, 6 Dec 2015 01:58:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1449367139; bh=4iPAr4o0QY1zvRojYbb/C7ZQL5ueh7IQZg4x5Qh4fGI=; l=5388; h=From:To:Date:References:In-Reply-To:From; b=bn+H/7eGs/OLC/QW5nndzEQYKIO09f6AijWFTUcGDtg79/U6DJSJ1Z05bGpnJ//Cd wVlJAyt+BkFzGkskPSTtRQ6FSXM5l2Y132Tqv1zbFr+IJEtvYRqrbXuyKQg4hiBwA/ eqBsepkPy55IQYh0D1tQGHUElh7UDqPufqTlZM3Y= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 65DAE2049; Sun, 6 Dec 2015 01:58:59 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sat, 5 Dec 2015 17:58:58 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Sat, 5 Dec 2015 20:58:58 -0500 From: "Salz, Rich" To: Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] Encrypted SNI Thread-Index: AQHRL4uDpc0zH797cEKmUXkuJX2tg569MnbA Date: Sun, 6 Dec 2015 01:58:58 +0000 Message-ID: <36a3b8e463f444ec9fd10c552ce702c4@usma1ex-dag1mb1.msg.corp.akamai.com> References: 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: [172.19.33.200] Content-Type: multipart/alternative; boundary="_000_36a3b8e463f444ec9fd10c552ce702c4usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 01:59:02 -0000 --_000_36a3b8e463f444ec9fd10c552ce702c4usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2FuIHdlIGVtYmVkIGFuIEVuY3J5cHRlZEV4dGVuc2lvbiBpbnNpZGUgYW4gZXhpc3RpbmcgRUU/ ICBUaGF0IHdvdWxkIGxldCB1cyBkbyBUT1IgcHVyZWx5IHdpdGhpbiBUTFMsIHJpZ2h0Pw0KDQpZ b3Ugc2FpZCDigJxpbiB0aGUgaW50ZXJlc3Qgb2YgZXhwbGljaXQgc2lnbmFsaW5n4oCdIGJ1dCBJ IHRoaW5rIHlvdSBtZWFudCBpbiB0aGUgaW50ZXJlc3Qgb2YgYXZvaWRpbmcgdGhhdCwgcmlnaHQ/ DQoNCkkgc3RpbGwgdGhpbmsgdGhlIOKAnGlubmVyL3JlYWwgU05J4oCdIGlzIHNpbXBsZXIsIGJ1 dCB3aWxsIGhhdmUgdG8gdGhpbmsgYWJvdXQgdGhlIHR3by4NCg0KLS0NClNlbmlvciBBcmNoaXRl Y3QsIEFrYW1haSBUZWNobm9sb2dpZXMNCklNOiByaWNoc2FsekBqYWJiZXIuYXQgVHdpdHRlcjog UmljaFNhbHoNCg== --_000_36a3b8e463f444ec9fd10c552ce702c4usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2FuIHdlIGVtYmVkIGFuIEVuY3J5cHRlZEV4 dGVuc2lvbiBpbnNpZGUgYW4gZXhpc3RpbmcgRUU/Jm5ic3A7IFRoYXQgd291bGQgbGV0IHVzIGRv IFRPUiBwdXJlbHkgd2l0aGluIFRMUywgcmlnaHQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Zb3Ugc2FpZCDigJxpbiB0 aGUgaW50ZXJlc3Qgb2YgZXhwbGljaXQgc2lnbmFsaW5n4oCdIGJ1dCBJIHRoaW5rIHlvdSBtZWFu dCBpbiB0aGUgaW50ZXJlc3Qgb2YgYXZvaWRpbmcgdGhhdCwgcmlnaHQ/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHN0 aWxsIHRoaW5rIHRoZSDigJxpbm5lci9yZWFsIFNOSeKAnSBpcyBzaW1wbGVyLCBidXQgd2lsbCBo YXZlIHRvIHRoaW5rIGFib3V0IHRoZSB0d28uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0tJm5ic3A7DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xv Z2llczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JTTogcmljaHNhbHpAamFiYmVyLmF0 IFR3aXR0ZXI6IFJpY2hTYWx6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_36a3b8e463f444ec9fd10c552ce702c4usma1exdag1mb1msgcorpak_-- From nobody Sat Dec 5 18:10:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749291B2EAF for ; Sat, 5 Dec 2015 18:10:15 -0800 (PST) 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 bFDvXPCSihK1 for ; Sat, 5 Dec 2015 18:10:14 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDB31B2E99 for ; Sat, 5 Dec 2015 18:10:14 -0800 (PST) Received: by ykba77 with SMTP id a77so161707885ykb.2 for ; Sat, 05 Dec 2015 18:10:13 -0800 (PST) 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=rcH8X1l+eZND90zHB8TIhOd1RO2QCubdjkVC7WgW+Io=; b=q1eLWMI92S6ejn9b6B1Y1XV2yNI8mZuJ0iVRLmb67PAnotsW2485g2bu+s7m0zlYMO qYp9xGVDGuPdvlKTAKXaJ4qgf+QxAwKjkqSalWmUJ/30n/HbCNNIobp0LTEXr2DoDZQj gCeQPU7dD/ARVpWCjo2rqlrfNg35YYfyMi++Ix98ccHissYsPDudx4PGItvzWuk375UT /O4YKDMs10d4rAR4DkcmiE73xq7w8LjFE+HKmb7WUF50CAW0sFPz3VQ1yjGOHNzCqnwE Yad5MWfvLRet8F0ZteCSvVM5PkxhvvNRWoh6StgsOTY9xcKKkgkgXaMaGlVW7kQ+BiU2 je8w== MIME-Version: 1.0 X-Received: by 10.129.57.135 with SMTP id g129mr15960719ywa.244.1449367813252; Sat, 05 Dec 2015 18:10:13 -0800 (PST) Received: by 10.129.148.131 with HTTP; Sat, 5 Dec 2015 18:10:13 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B9B509@uxcn10-5.UoA.auckland.ac.nz> References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <2977428.j4DNTR9LXR@pintsize.usersys.redhat.com> <20151016203610.GA5596@roeckx.be> <2348468.lpGyMim7ub@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B3DA@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9B509@uxcn10-5.UoA.auckland.ac.nz> Date: Sat, 5 Dec 2015 21:10:13 -0500 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 02:10:15 -0000 On Sat, Dec 5, 2015 at 8:18 PM, Peter Gutmann wrote: > Watson Ladd writes: >>On Sat, Dec 5, 2015 at 6:54 PM, Peter Gutmann wrote: >>> Hubert Kario writes: >>> >>>>miTLS does accept Application Data when it is send between Client Hello and >>>>Client Key Exchange and rejects it when it is sent between Change Cipher Spec >>>>and Finished. >>> >>> Given that miTLS is a formally verified implementation, would this imply that >>> there's a problem with the verification? "Beware of bugs in the above code; I >>> have only proved it correct, not tried it"? >> >>Are you saying there is a security flaw with the behavior described? > > I hadn't even thought it through to that point, more that you're not supposed > to accept anything between Client Hello and Client Keyex except an optional > Client Certificate. > > (OK, I haven't gone through every extension RFC and draft to see what else you > could poke in there, but I'm pretty sure Application Data isn't one of them). miTLS did not claim to be consistent with the RFC. Rather it claimed to be secure, and to interoperate with most other implementations in circumstances tested. The informal nature of the RFC makes it impossible to carry out formal verification against it. > > Peter. -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sat Dec 5 18:34:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DBC1B2F22 for ; Sat, 5 Dec 2015 18:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 GGTCM4debhQx for ; Sat, 5 Dec 2015 18:33:57 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC371B2F1F for ; Sat, 5 Dec 2015 18:33:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1449369237; x=1480905237; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3ybQ/gj718eSzhrB41e5uFMb3y2fnEsxqrVgQpP1los=; b=lydDgUe5uExT8eNsso9h3mOlztE0l8pKauuNPNZfsAmz4nEKGlg/dZEQ C1gTv0M3U2Lqw4Pw75QzXnhYB2K1iO4uAJO+C0sMQEDnirVVoYXtsbCWc 2L6JI7Z9Q6YW2B91jW40QkObn4xMNtdOFEoyBxq7XkiwrUHVFRpG4q/NB ba/db8Zbhw81F01mCy1ExA+kxOhfpRzKfgPDDitR7JTTyrBX+DHrEgHJX nADHzs2IUYT/MyDcMrBCT5OQuqMbhRFbd1fu7dQ+gdNThWLtFySFhmvw/ ct3o0+GJXxGANEy6Gc+wlX4f3cvCYMRHgUjfqfIFgW3P5NUGe+Pd+eLRG w==; X-IronPort-AV: E=Sophos;i="5.20,387,1444647600"; d="scan'208";a="57779493" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe3.UoA.auckland.ac.nz) ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Dec 2015 15:33:40 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Sun, 6 Dec 2015 15:33:39 +1300 From: Peter Gutmann To: Watson Ladd Thread-Topic: [TLS] Fwd: Clarification on interleaving app data and handshake records Thread-Index: AQHRLruiXKcfeysJmkanva71LFEja569EsIx//8tlYCAAOk3Kf//NYiAgADgXNE= Date: Sun, 6 Dec 2015 02:33:39 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B9B5C9@uxcn10-5.UoA.auckland.ac.nz> References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <2977428.j4DNTR9LXR@pintsize.usersys.redhat.com> <20151016203610.GA5596@roeckx.be> <2348468.lpGyMim7ub@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B3DA@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9B509@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 02:34:00 -0000 Watson Ladd writes:=0A= =0A= >miTLS did not claim to be consistent with the RFC. Rather it claimed to be= =0A= >secure, and to interoperate with most other implementations in circumstanc= es=0A= >tested. The informal nature of the RFC makes it impossible to carry out=0A= >formal verification against it.=0A= =0A= By that argument, you could start accepting SSH messages in the middle of t= he=0A= TLS handshake. No matter how you colour it, accepting Application Data aft= er=0A= a Client Hello is wrong. Is there any random, non-formally-verified=0A= implementation that would do that?=0A= =0A= Peter.= From nobody Sat Dec 5 18:44:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C241B2F3D for ; Sat, 5 Dec 2015 18:44:47 -0800 (PST) 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 oVamI_eDd7ME for ; Sat, 5 Dec 2015 18:44:46 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B3A1B2F3C for ; Sat, 5 Dec 2015 18:44:46 -0800 (PST) Received: by ykba77 with SMTP id a77so162078844ykb.2 for ; Sat, 05 Dec 2015 18:44:45 -0800 (PST) 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=kpQzMPkUg40D6L6d2riIn28SSpAPkADfRl4Vd1nnsG8=; b=uA3o6UrcIxT0d2T+ueDoRLz3ai8s6TmIgX9X7BmYycOIWXObDbhNpuzXz0R2dITiiV pGQ/3Y7Ff/v+RdhPyVQiHHeEWZlADHr1zPI/425hgagkJHdc0WAne8YUDzsgD4tkv/6I vI7VkGhRjeIILRhYLaZ4k8L+2yKYiFFB+Ytgr77anhUoyFCoAXPzE0CF5W8ysCApmkxH 9O8TsIjUiRV9VeGaFKswXr9qFqHEqKJGEbGhNKgl2FUhw1uIF10SWatwbzltSFBuVOvv VRNJO8LMzn9Dj7B2PMXAjIzAVWB7siZcQgkLzVv60gGcVd3LHeoV4RyVCWWQd6NHKtJN x/RQ== MIME-Version: 1.0 X-Received: by 10.129.90.85 with SMTP id o82mr17733789ywb.97.1449369885666; Sat, 05 Dec 2015 18:44:45 -0800 (PST) Received: by 10.129.148.131 with HTTP; Sat, 5 Dec 2015 18:44:45 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B9B5C9@uxcn10-5.UoA.auckland.ac.nz> References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <2977428.j4DNTR9LXR@pintsize.usersys.redhat.com> <20151016203610.GA5596@roeckx.be> <2348468.lpGyMim7ub@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B3DA@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9B509@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9B5C9@uxcn10-5.UoA.auckland.ac.nz> Date: Sat, 5 Dec 2015 21:44:45 -0500 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 02:44:47 -0000 On Sat, Dec 5, 2015 at 9:33 PM, Peter Gutmann wrote: > Watson Ladd writes: > >>miTLS did not claim to be consistent with the RFC. Rather it claimed to be >>secure, and to interoperate with most other implementations in circumstances >>tested. The informal nature of the RFC makes it impossible to carry out >>formal verification against it. > > By that argument, you could start accepting SSH messages in the middle of the > TLS handshake. No matter how you colour it, accepting Application Data after > a Client Hello is wrong. Is there any random, non-formally-verified > implementation that would do that? Any implementation where the record layer state is maintained separately from the handshake state will do this automatically. The only security issue is when data is intermingled across authentication boundaries, but once the record layer is told to encrypt at all that doesn't happen. If you disagree, please cite the sentence of the TLS RFC which prohibits accepting application data records during the handshake. > > Peter. -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sat Dec 5 18:49:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3841B2F53 for ; Sat, 5 Dec 2015 18:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 FB3ai0I4I-mp for ; Sat, 5 Dec 2015 18:49:00 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A8A1B2F52 for ; Sat, 5 Dec 2015 18:48:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1449370140; x=1480906140; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UFaNAs5hfi6DBaG8ZifVLhfTeeyuPztHw1ufZj+OdZU=; b=5s1bEvF+K+djtf8wpEJd6CcaQgbiI/YPM6+VCet9zimhCTEvHhdSBVhR fhA6JMCy4Rn0zp0v9U/eh//hxBa9U/qODFUKk0nCzrYLeXRHhZ6RrYfth d4SR8iO280gWvo1cJyCSd9PQdDKBBG6okNx4zSH83loXUhJQp6uGRF+Mj 9l7EfCICuAyBTEwDphG8olYfhQlCmWPMrcoUp2ATSaDBwmZdfCWBpt7Jj ZDs1J2GNHMDAv4NVnwnJRzgijfRTpImYuTvWNUNI3Q1YAarRtg50bAtGM dkAMYORXvhj4QtLrYSL2BqwMDZSV236adMQm++9dhKxoEc/0st+k++cOd g==; X-IronPort-AV: E=Sophos;i="5.20,388,1444647600"; d="scan'208";a="57780125" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Dec 2015 15:48:35 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Sun, 6 Dec 2015 15:48:35 +1300 From: Peter Gutmann To: Watson Ladd Thread-Topic: [TLS] Fwd: Clarification on interleaving app data and handshake records Thread-Index: AQHRLruiXKcfeysJmkanva71LFEja569EsIx//8tlYCAAOk3Kf//NYiAgADgXNH//ylKgAAbXE41 Date: Sun, 6 Dec 2015 02:48:33 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B9B61C@uxcn10-5.UoA.auckland.ac.nz> References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <2977428.j4DNTR9LXR@pintsize.usersys.redhat.com> <20151016203610.GA5596@roeckx.be> <2348468.lpGyMim7ub@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B3DA@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9B509@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9B5C9@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 02:49:02 -0000 Watson Ladd writes:=0A= =0A= >please cite the sentence of the TLS RFC which prohibits accepting applicat= ion=0A= >data records during the handshake.=0A= =0A= Please cite the sentence of the TLS RFC which prohibits accepting SSH messa= ges=0A= during the handshake.=0A= =0A= Please cite the sentence of the TLS RFC which prohibits executing=0A= /usr/games/hack during the handshake.=0A= =0A= Please cite the sentence of the TLS RFC which prohibits reformatting the=0A= user's hard drive during the handshake.=0A= =0A= (This debate is pointless and probably annoying everyone else, so I'll bow = out=0A= now).=0A= =0A= Peter.= From nobody Sat Dec 5 18:58:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A98F1B2F80 for ; Sat, 5 Dec 2015 18:58:35 -0800 (PST) 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 SvAvcT3nz19q for ; Sat, 5 Dec 2015 18:58:34 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E62D1B2F7E for ; Sat, 5 Dec 2015 18:58:34 -0800 (PST) Received: by ykba77 with SMTP id a77so162224845ykb.2 for ; Sat, 05 Dec 2015 18:58:33 -0800 (PST) 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=bFV/GjSPk2S4rRy5xHa2uZm5ydJlV+OtvVFvKUc21ok=; b=oCw7L3UtYbEpRY5oMOqntb+rBark+i2WFEgEdhR9APL1MYjpVlqAfhZimLal/HyWmQ shT7iHeYfWmor9Vhs9ovcaAUx6GK6B8OJydqMOfYyV9QXN/YkXhoVs7ESQq+NkB5Me/y DMI7ix9cF2+PxAl7ck0hc0i8DXa7nCXC1oPk8wLNpA8DURQRUPsMhnv8qoVFeaGcjhRL 4WgveRbmwzvCu5SvbzbZqGPYDuUH2l41SlEanHK0d8k8EJTUCDIr12feqErtiq72DuIo luA8YvPRbsoGZfwtiHYYCRkaf8d6KlLiClvRT5SrPAPVNGdkEMhchsPrJUUyRd5kw+dS lcPg== MIME-Version: 1.0 X-Received: by 10.129.57.135 with SMTP id g129mr16045807ywa.244.1449370713746; Sat, 05 Dec 2015 18:58:33 -0800 (PST) Received: by 10.129.148.131 with HTTP; Sat, 5 Dec 2015 18:58:33 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B9B61C@uxcn10-5.UoA.auckland.ac.nz> References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <2977428.j4DNTR9LXR@pintsize.usersys.redhat.com> <20151016203610.GA5596@roeckx.be> <2348468.lpGyMim7ub@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B3DA@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9B509@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9B5C9@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9B61C@uxcn10-5.UoA.auckland.ac.nz> Date: Sat, 5 Dec 2015 21:58:33 -0500 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 02:58:35 -0000 On Sat, Dec 5, 2015 at 9:48 PM, Peter Gutmann wrote: > Watson Ladd writes: > >>please cite the sentence of the TLS RFC which prohibits accepting application >>data records during the handshake. > > Please cite the sentence of the TLS RFC which prohibits accepting SSH messages > during the handshake. > > Please cite the sentence of the TLS RFC which prohibits executing > /usr/games/hack during the handshake. > > Please cite the sentence of the TLS RFC which prohibits reformatting the > user's hard drive during the handshake. > > (This debate is pointless and probably annoying everyone else, so I'll bow out > now). So what basis do you have for your assertion that you aren't supposed to accept data between Client Hello and Client Key Exchange? I think on the contrary that interleaved data was intended to be handled transparently: so long as the Finished message goes after the CCS message, with no intervening data, each record layer is associated to one of two handshakes unambiguously. > > Peter. -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sat Dec 5 19:07:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2841B2F9B for ; Sat, 5 Dec 2015 19:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 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, 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 q9_7H7TUYk_f for ; Sat, 5 Dec 2015 19:07:12 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625371B2F98 for ; Sat, 5 Dec 2015 19:07:12 -0800 (PST) Received: by ykba77 with SMTP id a77so162325870ykb.2 for ; Sat, 05 Dec 2015 19:07:11 -0800 (PST) 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=ZjjRx1vb/IWjio6E03aynIobnZwrKvwh+UApV2tEA6M=; b=biY2+olpMuMW12vUE/KgOosPzqab7gNs8nwEATouu3u4bfegTeayivSQpoKgoRV92C feVHtf//v9kpRz8jwvrUuAYo0Y4Q93zVOv7PGmRcVnQOjYp9YHdv923famhSkIDT4jDC O+mYLm5DH0Eyh21CeVMJSVK1EOrsQH/Q20rEo= 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=ZjjRx1vb/IWjio6E03aynIobnZwrKvwh+UApV2tEA6M=; b=BiKRD8hsAT500gh/vrpTDLpNQwo0L7JHeqVTHXeEGu91il48Y5MRcm22JQGcB31qOQ 4afSZwU7N+G9obwLKJPQuLAQtGLeKCHE6kexf4tOQPVyrlYfXFj+qqWD53AmVx6Hcoj0 U+58e4Ee4sCSh+y6B4TeXi52rdZQ/7Raq6yxFoFu8wVSSexd3ZYOeEm8pOXQn/qtoS0B u0IGgRsjSsktasXHlzEfi6LMCMWbSJ/btLq040AO477UqfiO1I0gdJRqLWouEM0sshaN aO9njHgYOBR7l/4X49AZYdALrM1WoqjyWHNWiDJLX7YmVgDWCDiRdKpwmyEL5y/t1/0C UJjg== X-Gm-Message-State: ALoCoQlOEp3KROLVHlkgTTJvCIqZ5D4bR3e6/gnwFjiw78pMMkBFbXlTS+G1anr2jws4Vd2XYKfN X-Received: by 10.13.200.70 with SMTP id k67mr16586491ywd.332.1449371231724; Sat, 05 Dec 2015 19:07:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.5.139 with HTTP; Sat, 5 Dec 2015 19:06:52 -0800 (PST) In-Reply-To: References: From: Tom Ritter Date: Sat, 5 Dec 2015 21:06:52 -0600 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 03:07:13 -0000 On 5 December 2015 at 12:32, Eric Rescorla wrote: > Subject: SNI Encryption Part XLVIII A small concern that probably is "No, that can't happen", but I would want to be sure that a normal (non-encrypted SNI) ClientHello would be unable to be wrapped in a new ClientHello to a gateway by a MITM (without being detected.) Also, I'm a little confused about what the client is supposed to put in the outer SNI (for the gateway). Is this blank? Some constant? Does this change at all in the simple deployment situation when there is no gateway involved, and everything sits on the same server? -tom From nobody Sat Dec 5 19:31:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DE21B29CF for ; Sat, 5 Dec 2015 19:31:48 -0800 (PST) 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, HTML_MESSAGE=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 tEpTvAk5YDBi for ; Sat, 5 Dec 2015 19:31:47 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AAAE1B29C7 for ; Sat, 5 Dec 2015 19:31:47 -0800 (PST) Received: by ykdv3 with SMTP id v3so162815482ykd.0 for ; Sat, 05 Dec 2015 19:31:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9kwpRWVnyW0bLqPu7JBFzvcYC4k4JklcP4H+Uy1HC/E=; b=SezHM4s3o675nHMMHalt0x7nmGwncaGeJ80qrelqayTIQokVPLOKntU3ZMXVaQBHsQ aqXz54VZB87aIdiQNHKI5cIF8OgtoRDZOVf49ZLpZELlKu5YfcQuvzfU3amKr+Nj+QGm Ng+FCLy4jl+ytkrnG2iWo42HwiIeHgn5jx46J4/mM9OHenLjSfVH8ijP8731rTWsvaM1 4QolaDnX/qaGKJp6Vx1atnQziCxsLaMD6bRD863k3Epmj15o7udb1g37yge6fbxpNRYL ddRrC9wHLt4kXf07v/uGveSqo5ypj5JJrhZ1bjF5X5/Goh8FSKVR/mDsJug3iU0DCgSu RbJA== 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=9kwpRWVnyW0bLqPu7JBFzvcYC4k4JklcP4H+Uy1HC/E=; b=nFh0pCXtOSHM8MwU19IcO3uX2oHU1Mg4mws2ZWBEePP4gaGP3WHbvbWEv3Z2IhXVRg hfLti3b53HI1EuoIuMifEZsM3AcC1FLnuUFu8zfY9MRCH0gIetnYWInN7mF/f52Q0M80 O7LjJOy6XV78/m7Hd3sLduunTtbJL1oUXnuGtT0d4jhadflT0bpiMeJmy+4gxYUEha3N qh7CG3xtignI4QbOUSUAPsUfQd+8V3ymiWnrsnGadpLYJgHMjPRpZwpy013BIvmZPf62 dgFD0GVstiS3WrIUf3WEpQ1eyt2KlMfG8u5+UKitp5LkyVM5CBzHIvVdY5QMSLSNBPPa 4jXw== X-Gm-Message-State: ALoCoQnpcPVfRfGeeO+f5kwBDiRKBW/5phHduHGiyNxC7/rVw96cABMvqOcDbKAVa+JMW86k6oCJ X-Received: by 10.129.73.198 with SMTP id w189mr19202497ywa.223.1449372706423; Sat, 05 Dec 2015 19:31:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Sat, 5 Dec 2015 19:31:06 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sat, 5 Dec 2015 19:31:06 -0800 Message-ID: To: Tom Ritter Content-Type: multipart/alternative; boundary=001a114dc81450786205263261d3 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 03:31:48 -0000 --001a114dc81450786205263261d3 Content-Type: text/plain; charset=UTF-8 On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter wrote: > On 5 December 2015 at 12:32, Eric Rescorla wrote: > > Subject: SNI Encryption Part XLVIII > > A small concern that probably is "No, that can't happen", but I would > want to be sure that a normal (non-encrypted SNI) ClientHello would be > unable to be wrapped in a new ClientHello to a gateway by a MITM > (without being detected.) > That would certainly be consistent with the proposed design. Why is that bad? Also, I'm a little confused about what the client is supposed to put > in the outer SNI (for the gateway). Is this blank? Some constant? Whatever SNI you would use to talk to the gateway ordinarily. Otherwise you would have a distinguisher. > Does > this change at all in the simple deployment situation when there is no > gateway involved, and everything sits on the same server? > No. -Ekr > > --001a114dc81450786205263261d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter <tom@ritter.vg> w= rote:
On 5 December 2015= at 12:32, Eric Rescorla <ekr@rtfm.com> wrote:
> Subject: SNI Encryption Part XLVIII

A small concern that probably is "No, that can't happen&quo= t;, but I would
want to be sure that a normal (non-encrypted SNI) ClientHello would be
unable to be wrapped in a new ClientHello to a gateway by a MITM
(without being detected.)



--001a114dc81450786205263261d3-- From nobody Sat Dec 5 19:32:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EA41B2A0D for ; Sat, 5 Dec 2015 19:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, T_RP_MATCHES_RCVD=-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 miU63mSHSPTS for ; Sat, 5 Dec 2015 19:32:37 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7572A1B29F6 for ; Sat, 5 Dec 2015 19:32:37 -0800 (PST) Received: by iouu10 with SMTP id u10so155195984iou.0 for ; Sat, 05 Dec 2015 19:32:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=94nN872xf1RAdDelzuBvXMF/6grvoyBikQ64CCYP+hw=; b=PSM5iYMt1vybMmuipOsCqGzs6sZeJiLzJmqux3NKzuAEUfo0TlgUVOkIj5CqMb6Tq+ XrrzkuPjyBcG/Z7+RIaf63d14snaU+oZr6t437WZSSA/SFiJ77yVXvOS+T/yWbZmX+/a AO16QJqAj75PpXiPC6iZ559hB83dI2FBT2SrySFJ/rpfmoVFt5ji5Ev7Mq4G2XDENQov HQQoAqN7GrUWlMi85QHPaSC8Iyr/n1BYLycq78uXr+2AmohDh3AqzWAY3TMEQ7w+shuy VghncOPv80jwwdGQStmkZvP3B2kgPORgURc1X+eI6cUTXMNTT+B2QDkZEEYYH54Ec0LO N9EA== 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=94nN872xf1RAdDelzuBvXMF/6grvoyBikQ64CCYP+hw=; b=dwxqKicLd97Z5aYZkE3yI0wNhPtvOIaSGh4Muc1hcAc8mU+nH9kuFJRdoS+XiPA3Vv +0WTWv5G5mSlMPh568aLpwG3L+GTOHP2Fm7pE5MAX5snXOUl+1f8mfpVieYP8GEApj2N yjT4MIfMYXhv2JBe7yg9hIO1w6NBl7aK0OWDrh0x6gaGLIY+utBN/FA4C7EyypZCiidc LwwKRWkmielGAP8r3XEiylPVUZGsx/uXfiR0UTHeKAEMigykLCXASujRAgxolx4zuFo9 61/cVBlaalei6SoAuypL8/kqSXDkg3MvoJhTRim/00CTZ0XadLiv9VK0zTVs/PGuq2m5 KLbA== X-Gm-Message-State: ALoCoQkx/CqcJNifjEvvxCNjhfA+7gdHJJil4aN8E1OwM92jruIz9cbe/yzKJc4VDL74EO2O7TLR MIME-Version: 1.0 X-Received: by 10.107.152.133 with SMTP id a127mr21389174ioe.60.1449372756783; Sat, 05 Dec 2015 19:32:36 -0800 (PST) Received: by 10.107.173.15 with HTTP; Sat, 5 Dec 2015 19:32:36 -0800 (PST) In-Reply-To: References: Date: Sat, 5 Dec 2015 19:32:36 -0800 Message-ID: From: Bill Cox To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1140e69e50ff3d0526326441 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Would there be security issues with a 0-RTT resume? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 03:32:38 -0000 --001a1140e69e50ff3d0526326441 Content-Type: text/plain; charset=UTF-8 On Sat, Dec 5, 2015 at 4:46 PM, Eric Rescorla wrote: > The intention *is* to have a 0-RTT resume, since PSK and 0-RTT should be > compatible. The spec may not be entirely clear on this point, though. > > -Ekr > Oh! Well, that's huge in some ways. I think the spec could use some more clarity here :) Bill --001a1140e69e50ff3d0526326441 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Dec 5, 2015 at 4:46 PM, Eric Rescorla <ekr@rtfm.com> wrote:
The intention *is* to have a 0-RTT resume= , since PSK and 0-RTT should be
compatible. The spec may not be e= ntirely clear on this point, though.

-Ekr

Oh!=C2=A0 Well, that's = huge in some ways.=C2=A0 I think the spec could use some more clarity here = :)

Bill
--001a1140e69e50ff3d0526326441-- From nobody Sat Dec 5 19:39:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06B81B2FF3 for ; Sat, 5 Dec 2015 19:39:35 -0800 (PST) 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, HTML_MESSAGE=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 Ah5RUTGPQxJn for ; Sat, 5 Dec 2015 19:39:34 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77BD71B2FF2 for ; Sat, 5 Dec 2015 19:39:34 -0800 (PST) Received: by ykdv3 with SMTP id v3so162895498ykd.0 for ; Sat, 05 Dec 2015 19:39:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kV9C/RlFp3z7bkcY+xU5e6rB8om6oXS78VP4y44RRLY=; b=v5X5DcunZrrfMumd0Y1iwPE/H4WtmYbMv5uC/nOgq8IkQmR16AhIhkyODJ1erQ/yF6 mBmmwI+/5v0Q6VDrw4YugR4xCu0r4xWXbLyxyo7ALfhMAvjPdrr2zeOPiQC/KZI677fB 3jWTgJ/Gath1XRZSPd8QtfLUQLfrLr4AZpYzWEzHUouMa5Mlmmtp/Ky8h8zsu9AOPuNr 6E/uKrdp35ooa2rW+kVUaJGc/TZ1K6BV/WbkRCmhRGPh37KbHDm2ftJpEOjZFHHsAPtG dv8muzfnbHAPUOdKTITU1/y7ApWzPfmDHS7CMwFYSqgM6W9kKYsT4X7C6d5/oo9CrOxE bAiQ== 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=kV9C/RlFp3z7bkcY+xU5e6rB8om6oXS78VP4y44RRLY=; b=a60b1H1ErpKVgGPAgTwC7ivuARtfQHTG5ozlEYpgMEgMdZzdoFp385Y+ClcG54aeRD CTOvtDFMF0lO4Cq7aPUvOrz0zSG+HESSFaBXzN/B/4W6xmyf94aPN+pi2mvqXFqQPxv3 Kiq2AZIyt6dZLV/hbbaadghK1Yqt1wMftvg2tw8VFI9wSI3QRaCZOnKs2x0hFJwK0sG2 75l5cQQAmio2WHK6weHwpeqR4COKSzwrhDpK3n7yOKg0vmHsMQlG83NKrDq07U/tvW1N FJ9EOtWW5v5cgJJU0DtPPGjlZFuwpBnIKvkqc3gWtBVFUoc+PaaV4kUkZmgUKa/hwtZP ErWg== X-Gm-Message-State: ALoCoQnrk3OlhmsfilJtR0OX7wmdupXDhX4DC/Cqq7ygxfrreIeAV4yrkmdmNO1DYfyaOUkxGp4L X-Received: by 10.129.148.3 with SMTP id l3mr2841417ywg.155.1449373173849; Sat, 05 Dec 2015 19:39:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Sat, 5 Dec 2015 19:38:54 -0800 (PST) In-Reply-To: <36a3b8e463f444ec9fd10c552ce702c4@usma1ex-dag1mb1.msg.corp.akamai.com> References: <36a3b8e463f444ec9fd10c552ce702c4@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eric Rescorla Date: Sat, 5 Dec 2015 19:38:54 -0800 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=94eb2c07c8bc2cd4960526327d07 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 03:39:35 -0000 --94eb2c07c8bc2cd4960526327d07 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Dec 5, 2015 at 5:58 PM, Salz, Rich wrote: > Can we embed an EncryptedExtension inside an existing EE? > I'm not sure I understand the design you're suggesting. > That would let us do TOR purely within TLS, right? > See above. > > You said =E2=80=9Cin the interest of explicit signaling=E2=80=9D but I th= ink you meant in > the interest of avoiding that, right? > No, I don't think so. One option would be to simply send a new tunneled application data type without any explicit signaling and the other would be to have an (encrypted) extension which indicated that that is what you are doing. I am endorsing the latter.. > I still think the =E2=80=9Cinner/real SNI=E2=80=9D is simpler, but will h= ave to think > about the two. > > > > -- > > Senior Architect, Akamai Technologies > > IM: richsalz@jabber.at Twitter: RichSalz > --94eb2c07c8bc2cd4960526327d07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Dec 5, 2015 at 5:58 PM, Salz, Rich <rsalz@akamai.com> wrote:

Can we embed an Encrypted= Extension inside an existing EE?

I'm not sure I understand the design you're suggesting= .

=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=C2=A0 That would let us do TOR purely within TLS= , right?


See above.<= /div>


=C2=A0

You said =E2=80=9Cin the = interest of explicit signaling=E2=80=9D but I think you meant in the intere= st of avoiding that, right?


No, I don't think so. One option would be to simply send a new = tunneled application data
type without any explicit signaling and= the other would be to have an (encrypted) extension which indicated that t= hat is what you are doing. I am endorsing the latter..

=
=C2=A0

I still think the =E2=80= =9Cinner/real SNI=E2=80=9D is simpler, but will have to think about the two= . =

=C2=A0

--=C2=A0

Senior Architect, Akamai = Technologies

IM: richsalz@jabber.at Twitter: RichSalz=


--94eb2c07c8bc2cd4960526327d07-- From nobody Sat Dec 5 20:20:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0C01B30A9 for ; Sat, 5 Dec 2015 20:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 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, 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 yusxAudjF5hK for ; Sat, 5 Dec 2015 20:20:25 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65DD21B30A7 for ; Sat, 5 Dec 2015 20:20:25 -0800 (PST) Received: by ykfs79 with SMTP id s79so164361903ykf.1 for ; Sat, 05 Dec 2015 20:20:24 -0800 (PST) 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=mQlHFZXPfX+lArognhzj5ZYqezdQhYCfRkQg5IZcCFA=; b=NOas0AUWKt25GxcP7gKvUabCV9/eK/KDC4zCwazUljMbWF6yHVbT9MxfGWfnb6jQgu cpiQf9sJi4A5WaSDmBnZR1018XU0WH+TXU8jjmkUKiXS0XENiWMNFKuHf7J9ozrGpPfK CPEmOGHtwEOjofycnXelvivkibpk5rbDE2pZE= 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=mQlHFZXPfX+lArognhzj5ZYqezdQhYCfRkQg5IZcCFA=; b=Iu3tBVIQv4jf7ofIW9ptAo0G7wQ2YO/BCD2RKuRyofJAwdDSri1/zFbG2+ID30nX9V 3TnUP9x/0s0k57ucdYwr2nyNrP8GhY9hkBmgQzGqyByVRPdEodu5lrYETcuvA2B3AaKn ciwi8evkgzzdk58n+lcKJC+yx3wNd5J63Kgpnbt68d9Ke9Z4rkHexoBXvEP4WuHmkUfL Qm3bXruVclkx+sX6d2FQdO2RiXBLkl67S4YguTnPI80khDY9rsMRji4A1vnqZCxQKc00 u7Y8WUM/JkORcZhxd3hXBZQPlG/gN1mGHLNDqZ1B1Frs8ISA9dzqtOR+VvnWsk9GLuBJ OkuA== X-Gm-Message-State: ALoCoQkkEKqPPiCb0tqtAdgCXlDw6W6QUoFf5nQSDR5FPlNNVcschCWTT6C/BppignaDovnzucgr X-Received: by 10.13.194.193 with SMTP id e184mr16983422ywd.203.1449375624729; Sat, 05 Dec 2015 20:20:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.5.139 with HTTP; Sat, 5 Dec 2015 20:20:05 -0800 (PST) In-Reply-To: References: From: Tom Ritter Date: Sat, 5 Dec 2015 22:20:05 -0600 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 04:20:30 -0000 On 5 December 2015 at 21:31, Eric Rescorla wrote: > > > On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter wrote: >> >> On 5 December 2015 at 12:32, Eric Rescorla wrote: >> > Subject: SNI Encryption Part XLVIII >> >> A small concern that probably is "No, that can't happen", but I would >> want to be sure that a normal (non-encrypted SNI) ClientHello would be >> unable to be wrapped in a new ClientHello to a gateway by a MITM >> (without being detected.) > > > That would certainly be consistent with the proposed design. Why is that > bad? It doesn't seem safe that a MITM can actively change the way a handshake occurs and is processed by the other side without being detected. It's like asking for some sort of more complex attack. We don't allow a MITM to change other parts of the handshake. A trivial, though contrived, example could be a CDN that supports eSNI. All requests it receives from... Turkmenistan[0] use eSNI. Seems good? Actually the government blocks all client-originated eSNI requests and re-wraps them so to the outside world it appears less censored than it is. Could be done state-wide or (if god forbid we had a fallback) to individual clients. Something analogous is not allowing an attacker to inject a HelloRetryRequest.We shouldn't allow that, either I think. I looked at #104 - it seems like the current plan _is_ to restart the handshake hash in the event of HelloRetryRequest but that a server cookie must be replayed? (Theorizing the cookie is an HMAC containing the client ip and some other things?) I think there's an attack on that if an attacker can forge packets from a client. (HelloRetryRequest is not signed by the server, right?) Client supports SecureA, SecureB, and InsecureC. Server supports SecureA, SecureB, and InsecureC. Client sends a ClientHello with KeyShares for A & B. Attacker forges a packet from the client's IP with support for C and RandomD and KeyShares for RandomD. Server replies with a HelloRetryRequest with a cookie for that client IP. Attacker forges a HelloRetryRequest from the server, copying the cookie, and saying "I only support InsecureC." The attacker sends the forged HelloRetryRequest to the client. Client makes a KeyShare for InsecureC and sends it along with the cookie, which the server recognizes as being from it for the IP, and everything proceeds using InsecureC undetectably. I think. >> Also, I'm a little confused about what the client is supposed to put >> in the outer SNI (for the gateway). Is this blank? Some constant? > > Whatever SNI you would use to talk to the gateway ordinarily. Otherwise > you would have a distinguisher. But... what is that? If I look up example.com (over my new private DNS link) and get an IP back to a CDN (which I wouldn't even know)... how would I know what the "normal gateway SNI" is? -tom [0] To use a real-world example of a heavily censored national internet. From nobody Sat Dec 5 20:32:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365381B30CE for ; Sat, 5 Dec 2015 20:32:02 -0800 (PST) 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, HTML_MESSAGE=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 b7OHc3aJtTFD for ; Sat, 5 Dec 2015 20:32:00 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13E5A1B30CD for ; Sat, 5 Dec 2015 20:32:00 -0800 (PST) Received: by ykdv3 with SMTP id v3so163436775ykd.0 for ; Sat, 05 Dec 2015 20:31:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=C6UpohFtDLfCPMsyzH4r2fYpceahGJ9D06VzAvl/ClE=; b=wtmia6+m1QJn1JLddFrc7DKwvJzXk9iXCvu605ZL+EKEOwqTVOpTU3RzKl8xB5441N 6uOTmzGUwWLYoifiOMBMmc9eZ3Oqc3F74rXhebGw724wRLq0Gl7KngOPyJCxMUHE0nOm SJaCVi6lx6r4Igs7mmE81g3hM3M4/iqCs3R5341fcbL1MlGe5MBNIMuy1+Xh+S9uRai/ Pt7bBAp96Cvx00GcuFrCKy6THtF6IUc8RpGLqsnaM/Q6cILVpWuYYIC6TGKQpXHlnjb1 pLTI9xaskuhn7Q9vtvIUfPLNcdS6ws/7YCwzRVpcdnHwDP8erjcjDJirv4gHJPxZR4r6 5aeg== 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=C6UpohFtDLfCPMsyzH4r2fYpceahGJ9D06VzAvl/ClE=; b=HGS/f6WG2qFKpLNVMmcpXLZwYc7iMknCXtV3XjoSjHYGgpilYdf9K5rQlRHPLJdAwj Kq88VpP7kW+OeFMvnSnMGTEw+9Kr/Ml7xczn+LHXpnjnEVRSgkHyKqw/QsDJmOu2Vwas XeG+bUlrvTACYriYScV35/shAFKQassZPfHdoQAjyc+zsHiRwlLrjOoTtcujxRNrkVyW kegofWxGU8hYh0kusw6ztSpSirLPyB3IoragSxPHuClKUAVqNmqPPI5WQQ6mhmNKMUuA PngIRaOqWpRTA3cyZOoDrZjBiwK4vQ/QCeOzKomZ9/XzDq0Fuu7WpT48n2DSwAZYGpuJ T0NQ== X-Gm-Message-State: ALoCoQlyYpPPBOfW8XPY5BT780znOSFWgJEZ9RzLHWGxsUR2K4RDHL2fmUjK0OjT8sKWXwlhvPE/ X-Received: by 10.129.148.3 with SMTP id l3mr2929883ywg.155.1449376319389; Sat, 05 Dec 2015 20:31:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Sat, 5 Dec 2015 20:31:20 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sat, 5 Dec 2015 20:31:20 -0800 Message-ID: To: Tom Ritter Content-Type: multipart/alternative; boundary=94eb2c07c8bca9ee6b052633384b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 04:32:02 -0000 --94eb2c07c8bca9ee6b052633384b Content-Type: text/plain; charset=UTF-8 On Sat, Dec 5, 2015 at 8:20 PM, Tom Ritter wrote: > On 5 December 2015 at 21:31, Eric Rescorla wrote: > > > > > > On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter wrote: > >> > >> On 5 December 2015 at 12:32, Eric Rescorla wrote: > >> > Subject: SNI Encryption Part XLVIII > >> > >> A small concern that probably is "No, that can't happen", but I would > >> want to be sure that a normal (non-encrypted SNI) ClientHello would be > >> unable to be wrapped in a new ClientHello to a gateway by a MITM > >> (without being detected.) > > > > > > That would certainly be consistent with the proposed design. Why is that > > bad? > > It doesn't seem safe that a MITM can actively change the way a > handshake occurs and is processed by the other side without being > detected. It's like asking for some sort of more complex attack. We > don't allow a MITM to change other parts of the handshake. > > A trivial, though contrived, example could be a CDN that supports > eSNI. All requests it receives from... Turkmenistan[0] use eSNI. Seems > good? Actually the government blocks all client-originated eSNI > requests and re-wraps them so to the outside world it appears less > censored than it is. Could be done state-wide or (if god forbid we had > a fallback) to individual clients. > Fair enough. This seems easily solved by requiring the internal ClentHello to enclose a digest of the external ClientHello in some extension. Something analogous is not allowing an attacker to inject a > HelloRetryRequest.We shouldn't allow that, either I think. I looked at > #104 - it seems like the current plan _is_ to restart the handshake > hash in the event of HelloRetryRequest but that a server cookie must > be replayed? No, that's not the current plan. See: http://www.ietf.org/mail-archive/web/tls/current/msg18118.html > (Theorizing the cookie is an HMAC containing the client > ip and some other things?) I think there's an attack on that if an > attacker can forge packets from a client. (HelloRetryRequest is not > signed by the server, right?) > > Client supports SecureA, SecureB, and InsecureC. Server supports > SecureA, SecureB, and InsecureC. Client sends a ClientHello with > KeyShares for A & B. Attacker forges a packet from the > client's IP with support for C and RandomD and KeyShares for RandomD. > Server replies with a HelloRetryRequest with a cookie for that client > IP. Attacker forges a HelloRetryRequest from the server, copying the > cookie, and saying "I only support InsecureC." The attacker > sends the forged HelloRetryRequest to the client. Client makes a > KeyShare for InsecureC and sends it along with the cookie, which the > server recognizes as being from it for the IP, and everything proceeds > using InsecureC undetectably. I think. > Well the client sends shares for A, B, and C (it is required to append the new share to the list, not replace it) for exactly this reason. So, as long as the server would prefer A or B given A, B, and C, you don't end up with C. However, as I said, we are not planning to restart the handshake hash. >> Also, I'm a little confused about what the client is supposed to put > >> in the outer SNI (for the gateway). Is this blank? Some constant? > > > > Whatever SNI you would use to talk to the gateway ordinarily. Otherwise > > you would have a distinguisher. > > But... what is that? If I look up example.com (over my new private > DNS link) and get an IP back to a CDN (which I wouldn't even know)... > how would I know what the "normal gateway SNI" is? Well, this isn't what would happen. You would get a response in something other than an A record that contained "here is the DNS name of the gateway". That's the only thing that can work because you need to solicit the ServerConfig from the gateway in any case. I don't see how to make this work without a channel richer than just an IP, since the client needs to know how to do Encrypted SNI. -Ekr > -tom > > [0] To use a real-world example of a heavily censored national internet. > --94eb2c07c8bca9ee6b052633384b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Dec 5, 2015 at 8:20 PM, Tom Ritter <tom@ritter.vg> w= rote:
On 5 December 2015 at 21:31, Eric Rescorla = <ekr@rtfm.com> = wrote:
>
>
> On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter <tom@ritter.vg> wrote:
>>
>> On 5 December 2015 at 12:32, Eric Rescorla <ekr@rtfm.com> wrote:
>> > Subject: SNI Encryption Part XLVIII
>>
>> A small concern that probably is "No, that can't happen&q= uot;, but I would
>> want to be sure that a normal (non-encrypted SNI) ClientHello woul= d be
>> unable to be wrapped in a new ClientHello to a gateway by a MITM >> (without being detected.)
>
>
> That would certainly be consistent with the proposed design. Why is th= at
> bad?

It doesn't seem safe that a MITM can actively change the way a handshake occurs and is processed by the other side without being
detected. It's like asking for some sort of more complex attack. We
don't allow a MITM to change other parts of the handshake.

A trivial, though contrived, example could be a CDN that supports
eSNI. All requests it receives from... Turkmenistan[0] use eSNI. Seems
good? Actually the government blocks all client-originated eSNI
requests and re-wraps them so to the outside world it appears less
censored than it is. Could be done state-wide or (if god forbid we had
a fallback) to individual clients.

Fair= enough. This seems easily solved by requiring the internal
Clent= Hello to enclose a digest of the external ClientHello in some
ext= ension.


Something analogous is not allowing an attacker to inject a
HelloRetryRequest.We shouldn't allow that, either I think. I looked at<= br> #104 - it seems like the current plan _is_ to restart the handshake
hash in the event of HelloRetryRequest but that a server cookie must
be replayed?

No, that's not the current= plan. See:

=C2=A0
(Theorizing the cookie is an HMAC containing the client
ip and some other things?) I think there's an attack on that if an
attacker can forge packets from a client. (HelloRetryRequest is not
signed by the server, right?)

Client supports SecureA, SecureB, and InsecureC. Server supports
SecureA, SecureB, and InsecureC. Client sends a ClientHello with
KeyShares for A & B. <Pause> Attacker forges a packet from the client's IP with support for C and RandomD and KeyShares for RandomD. Server replies with a HelloRetryRequest with a cookie for that client
IP. Attacker forges a HelloRetryRequest from the server, copying the
cookie, and saying "I only support InsecureC." <Unpause> Th= e attacker
sends the forged HelloRetryRequest to the client. Client makes a
KeyShare for InsecureC and sends it along with the cookie, which the
server recognizes as being from it for the IP, and everything proceeds
using InsecureC undetectably.=C2=A0 =C2=A0I think.
Well the client sends shares for A, B, and C (it is required to= append
the new share to the list, not replace it) for exactly th= is reason. So, as long
as the server would prefer A or B given A,= B, and C, you don't end
up with C. However, as I said, we ar= e not planning to restart the handshake
hash.


>> Also, I'm a little confused about what the client is supposed = to put
>> in the outer SNI (for the gateway). Is this blank? Some constant?<= br> >
> Whatever SNI you would use to talk to the gateway ordinarily. Otherwis= e
> you would have a distinguisher.

But... what is that?=C2=A0 If I look up example.com (over my new privat= e
DNS link) and get an IP back to a CDN (which I wouldn't even know)... how would I know what the "normal gateway SNI" is?

Well, this isn't what would happen. You would get a r= esponse in something
other than an A record that contained "= here is the DNS name of the gateway".
That's the only th= ing that can work because you need to solicit the ServerConfig
fr= om the gateway in any case. I don't see how to make this work without
a channel richer than just an IP, since the client needs to know h= ow to do
Encrypted SNI.

-Ekr
<= br>

=C2=A0
-tom

[0] To use a real-world example of a heavily censored national internet.

--94eb2c07c8bca9ee6b052633384b-- From nobody Sat Dec 5 22:59:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CE51A0378 for ; Sat, 5 Dec 2015 22:59:39 -0800 (PST) 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 QhnmPbWSafD5 for ; Sat, 5 Dec 2015 22:59:38 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E149A1A0373 for ; Sat, 5 Dec 2015 22:59:37 -0800 (PST) Received: by wmww144 with SMTP id w144so105923638wmw.1 for ; Sat, 05 Dec 2015 22:59:36 -0800 (PST) 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=w46pxY+K4LyDLjIX9L4JEzdptHGQwkroxAIxCXSGCbs=; b=y4//uVUD1qITaYFm+vaIX6FdAqCI0eusMJonQSZRJ+m7keHi/eN3BGW2tp71AKDzbp hy9bLZFQSlsk+hGDZDt/P8fcKH9ZiyWHDNNd/LIucCy1XLh20VyxO9EqAB0GSJWFhxqt R4QJdfDIJJ+dpQwF4RywR8gh/4WCUXpCREuQRXRxavOTC6ag6rNGE2xUwZ/dFDeo0D8V 8g7MyZP6Vy3gsk8h2QU8hc65olp3XXyOxARiTC93Knn26H87EybKSrOMi2/Dokic2S/n WIUnOia6kCkVqPwWqSKShXYJAiIynhTlO1rVB8MLB3ddn73zZPY5XHyxR8vV7Dbibj+R Ua6A== X-Received: by 10.28.188.84 with SMTP id m81mr13441611wmf.38.1449385176589; Sat, 05 Dec 2015 22:59:36 -0800 (PST) Received: from yoavs-mbp.mshome.net ([176.12.139.87]) by smtp.gmail.com with ESMTPSA id r74sm10817091wmb.2.2015.12.05.22.59.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 05 Dec 2015 22:59:35 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: Date: Sun, 6 Dec 2015 08:59:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8DCA2D60-443F-41C1-82A2-294FD16D15D7@gmail.com> References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <2977428.j4DNTR9LXR@pintsize.usersys.redhat.com> <20151016203610.GA5596@roeckx.be> <2348468.lpGyMim7ub@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B3DA@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9B509@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9B5C9@uxcn10-5.UoA.auckland.ac.nz> To: Watson Ladd X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 06:59:39 -0000 > On 6 Dec 2015, at 4:44 AM, Watson Ladd wrote: >=20 > If you disagree, please cite the sentence of the TLS > RFC which prohibits accepting application data records during the > handshake. OK, I=E2=80=99ll bite. Top of page 36: Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Figure 1. Message flow for a full handshake See? Application data goes *after* the Finished message. Not between = ClientHello and anything else. Now this swim track diagram may not look = like a formal definition, but RFCs are written to be processed by = humans, not computers. If I add some application data in the middle = there like this: Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Application Data ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Any human can see that this is not the same as what=E2=80=99s in Figure = 1, and thus is wrong. We don=E2=80=99t need the RFC to provide a regular = expression or a state machine diagram to figure that out. Yoav From nobody Sat Dec 5 23:42:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988041A1AFC for ; Sat, 5 Dec 2015 23:42:55 -0800 (PST) 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 8uT2tJy9p3oI for ; Sat, 5 Dec 2015 23:42:54 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 551621A1ADC for ; Sat, 5 Dec 2015 23:42:54 -0800 (PST) Received: by qgec40 with SMTP id c40so122235761qge.2 for ; Sat, 05 Dec 2015 23:42:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=iZ3+D0egYAqgIfFs/nLvcW0Yx3VRHTSKiJw9oYHHCY0=; b=UqcvQ51pFUFSP8Yta0LHtSmUYfnaDeWSTMtNpvd/j4dlT2sVd66XbmIKMV4Akja9Ae CwJgviD5cXBqeDR1hMvhxFOMe1fp2p0YAboC1dCqaShTeHv0sfmoWya4p2lgsI6rGznF n8uonvyXjyR/G+FMaOpi57F4SMIhlNHFYfD3cuqhdoOzN/D9HKu26tmh30kqCE6pScSr 9iP0qO084yoHdrfl4InV3RmxAPrOCSizp9rpZQpqEbu3FOhTbhmmjCB25mpqUFysKe0l e8uc3kndxb1Th1O0uHWKjuSSeWHC6uwnsCiAnN8JbeiMq2ROY1nYk0fzWfFn8XG9JA1H ttYg== X-Received: by 10.140.232.65 with SMTP id d62mr30993635qhc.27.1449387773598; Sat, 05 Dec 2015 23:42:53 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id j89sm9173355qgj.35.2015.12.05.23.42.52 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 05 Dec 2015 23:42:53 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Sun, 6 Dec 2015 02:42:51 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <36a3b8e463f444ec9fd10c552ce702c4@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <36a3b8e463f444ec9fd10c552ce702c4@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201512060242.51979.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 07:42:55 -0000 On Saturday, December 05, 2015 08:58:58 pm Salz, Rich wrote: > Can we embed an EncryptedExtension inside an existing EE? That would let us do TOR purely within TLS, right? If clients are allowed to send any encrypted extensions other than the tunneling extension (that contains the tunneled hello), then we would have to allow sending an EncryptedExtension through it, otherwise tunneled peers would have less capabilities than non-tunneled. I don't see anything in this design that would prohibit recursively doing this as many times as desired. (e.g. tunnel of a tunnel of a tunnel of a...) That does sound somewhat TOR-like, though obviously, lots more would be needed to actually do anything with that. If this can actually be done, it sounds very promising. Dave From nobody Sun Dec 6 00:48:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8E21ACCE9 for ; Sun, 6 Dec 2015 00:48:39 -0800 (PST) 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] 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 LVoOFNgTn2KT for ; Sun, 6 Dec 2015 00:48:38 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33BA71ACD0C for ; Sun, 6 Dec 2015 00:48:38 -0800 (PST) Received: by iouu10 with SMTP id u10so158109016iou.0 for ; Sun, 06 Dec 2015 00:48:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=APXOvXaiEKT6NGa26qQVQdTT28IyVN7Ic6eCcZSVKYo=; b=AG0hYuf9eQsDtRMZULKt8hh86D7Csph5XzP0tyNjkNa9n7mt1gmpMcNFjaVkaHdGCR IEONATAg1zZcxQOCB+eLkzyI52pFtTuGLbggdpd9v/eJs5jYywRrnBsW0h2gveFBKNBH SkQfi3azMb/3LUU47DN+OtaRXf9QQJrxalOZVqHlW/Nl74MTXumVnNcekByzlWKvMgNZ BTbrmBZiqo0LX/YDUs51B0P7ynzLY6S7NxVZDx5BF7n0rB5FO8EtSgGkwH6PqcJiqyht HJ10bKo6xPJwrxzjN3eW9B96TvHmgWlGZ66LvhNFgBpJ6euGcq6fMTH7yOZALHCJQMga UsWw== 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=APXOvXaiEKT6NGa26qQVQdTT28IyVN7Ic6eCcZSVKYo=; b=BSTeUTXkpkga3VeNnpxH/WLJQsIGf1SxuQYgMZXPdLL3//PWwZndZVNe1cAMC5yTlp 2CRALqKPltzGDsTtPwYcaDn52SD4aOMqKPWIUBfVe3cEh2MiZ03xmdjlt1QA8CP0SIMF yt3tVn/1EjBMvLnMCeIKfPELH5jyLzxEoEk/zV6ZIl/5jRUS9TOZZ4gQ/DfALfu7C7kd Y9u8Aa3pmg4JDVeU0y5hYWYFaIC+15PHJeMBa17zc1jHH9ey66TSyn0EFiXfrZgrSS0f Hsz2nT9FoJFuVRrHm7jIQ4EzMQbeHEJGUGj13UdNAi9t0MvFSq7VgqySAt/K7t+jNglU KDSg== X-Gm-Message-State: ALoCoQlDA3g2QfrujhDBYj163KYmG9V/D7tmwTJBl9Ly9+pbq/tOxsX68YZdToyieiCkrdLnCBoG MIME-Version: 1.0 X-Received: by 10.107.137.19 with SMTP id l19mr18772585iod.138.1449391717566; Sun, 06 Dec 2015 00:48:37 -0800 (PST) Received: by 10.79.70.71 with HTTP; Sun, 6 Dec 2015 00:48:37 -0800 (PST) X-Originating-IP: [18.238.2.85] In-Reply-To: <201512060242.51979.davemgarrett@gmail.com> References: <36a3b8e463f444ec9fd10c552ce702c4@usma1ex-dag1mb1.msg.corp.akamai.com> <201512060242.51979.davemgarrett@gmail.com> Date: Sun, 6 Dec 2015 08:48:37 +0000 Message-ID: From: Jacob Appelbaum To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 08:48:39 -0000 On 12/6/15, Dave Garrett wrote: > On Saturday, December 05, 2015 08:58:58 pm Salz, Rich wrote: >> Can we embed an EncryptedExtension inside an existing EE? That would let >> us do TOR purely within TLS, right? > > If clients are allowed to send any encrypted extensions other than the > tunneling extension (that contains the tunneled hello), then we would have > to allow sending an EncryptedExtension through it, otherwise tunneled peers > would have less capabilities than non-tunneled. I don't see anything in this > design that would prohibit recursively doing this as many times as desired. > (e.g. tunnel of a tunnel of a tunnel of a...) That does sound somewhat > TOR-like, though obviously, lots more would be needed to actually do > anything with that. If this can actually be done, it sounds very promising. > I had a similar thought. There needs to be a way to blind each server that is two hops away to make it work: Alice connects to a server_0, the server routes to server_1, server_1 routes to server_2 and that passes the final TLS to Bob. Alice's TLS message needs to be passed to server_1 without every indicating in an encrypted fashion that server_2 is in the path. In this analogy, server_0 is like the Tor guard, server_1 is the middle node, and server_2 is the exit node. There are some issues with such a design - which is why Tor's design is to use TLS as an outer link layer and then internally to use 512 byte (or slightly larger) cells. I won't get into those here but I find the general idea of tls within tls to be useful. All the best, Jacob From nobody Sun Dec 6 01:22:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F421A88A9 for ; Sun, 6 Dec 2015 01:22:07 -0800 (PST) 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 i7E9nCYl_QOy for ; Sun, 6 Dec 2015 01:22:01 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0081A88B2 for ; Sun, 6 Dec 2015 01:21:55 -0800 (PST) Received: by wmec201 with SMTP id c201so127472765wme.0 for ; Sun, 06 Dec 2015 01:21:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=4NLqfl+7ZF0a7dZ2Fmolqltjhg99Re/jexBBjmpQuT4=; b=BW1VFVbqszMosQV9dJShhGbDaZs+vYC6U69pDmqH9i6L3dEcHj2bbRcLYDOmFdUGLm ABMwFKX0E0FQ+ttn5igHx0kbM6FBGxO43Zji0whDCDTXRKln8XTldwm1F+mZFuF8Cw9x ScsaE8IUQ/MLc9FKu4GaKm7OcgV2+2/EP+zwL0MrueKv7/ewPB4OB6wp7gPOmrP1u3vK hWZ6OtP31D/LWv98zFtP2qMr/jvoRGQEy9AIOE/QnPxaSJw1I1OENbcBCj6APLWTpdb0 570xlHKkCfHHfSzHX53XGbzCzz8ybhCB+lrv+vcfiTWvMpxMGcdYyEAujeNVT+VEi7zk vLxw== X-Received: by 10.195.18.6 with SMTP id gi6mr29199778wjd.83.1449393713521; Sun, 06 Dec 2015 01:21:53 -0800 (PST) Received: from proz.dclient.lsne.ch (85-218-12-53.dclient.lsne.ch. [85.218.12.53]) by smtp.gmail.com with ESMTPSA id h4sm19702769wjx.41.2015.12.06.01.21.51 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Dec 2015 01:21:51 -0800 (PST) To: tls@ietf.org References: <11f501d12ed6$41150270$c33f0750$@augustcellars.com> From: Bryan A Ford X-Enigmail-Draft-Status: N1110 Message-ID: <5663FE47.1050106@gmail.com> Date: Sun, 6 Dec 2015 10:22:15 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <11f501d12ed6$41150270$c33f0750$@augustcellars.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090702080005030704040406" Archived-At: Subject: Re: [TLS] Analysis of encrypting the headers - what is the length X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 09:22:07 -0000 This is a cryptographically signed message in MIME format. --------------ms090702080005030704040406 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/4/15 9:56 PM, Jim Schaad wrote: > I will start by re-iterating my initial position that I would prefer th= at > the DTLS and TLS analysis is going to be the same in terms of masking t= he > header information. So I decided to do some thought experiments about = what > happens if the length were to be encrypted and how many different situa= tions > does this not appear to help the situation. Why are you fixated on enumerating different situations where encrypting headers doesn't help, while completely ignoring situations where it can help? You could draw up an infinite list of scenarios in both categories. No security provision will address every possible attack scenario - padding definitely doesn't either! - but both header encryption and padding are complementary provisions that each make attacks more difficult for attackers in different ways. B --------------ms090702080005030704040406 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwNjA5MjIxNVowLwYJKoZIhvcNAQkEMSIEIGOuEPufitCae9WWPspppPwueB1+wJdBLQa1 5rs6keoyMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBAFXUtQ9xj+dbxVBU 3SHMLuxOne1bIp93cETvKjkRGSTM/0QEaVLqaBCblIwdcwHyR0GzgAODiEXD6pNgilzgEJ7O 7K+9n1Hb1MBvvkOxt4YZ0tt5TvSQg5XcRXcPIDs2EgGxGFtP5Vfq3bsygG/DVjeUxpcmv+Q7 K+fmkbnVlPxgimf++jG8owpCvRH2RPBxtgBE7KbuN06/LkQZrja/vLQCogavWwuCNTdKci22 N763vfaVLLUFK3xJVn/EG9eVky2eefMdcNLP+DiMxsiH5rO49nqO0HgfSYoxBGcPbT+LzE/X RHvYwJ2VR66ivlkgYAp44CwOSixgjNOLqllkOXEAAAAAAAA= --------------ms090702080005030704040406-- From nobody Sun Dec 6 02:14:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FEB1ACD0A for ; Sun, 6 Dec 2015 02:14:51 -0800 (PST) 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 9BLe5g_g7lNk for ; Sun, 6 Dec 2015 02:14:49 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39CFD1ACD02 for ; Sun, 6 Dec 2015 02:14:49 -0800 (PST) Received: by wmvv187 with SMTP id v187so129093028wmv.1 for ; Sun, 06 Dec 2015 02:14:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type; bh=EkmgTvmQ8eEyyAn9KqW/oY0P1gAzjaKWQTPplFne1dw=; b=HKT0/o6qfzi/YK54VCPpozZO38NgJe4PKy+AVmweWiEBcBtQxoYLxG+vdpMNmKKJkM lnQiW1/aw36APFR7z+0O4sazDs9vli/ifScVIWp40lVOnZbmdGyFsOz8niD07S9F8NtZ r2EEyWNK2TtkOLGcDg8KfuWPAipdkdFbMi71YP8mcpr+PDFN+oV22zad+rxHRlZkimqO NX9FHz482VpjaHfwNKdCokPua8OnGcgKTPR8zvavg5WS4BeCW3PsQYd2Zq/gXjr824UM 86dFD3A8iuZAoGpr73f5NuBuvLX0I1tnTB/udrgT0ktmpHKL2V6Z1k66F+tC2Hztg6ox fHlQ== X-Received: by 10.28.156.83 with SMTP id f80mr15548034wme.41.1449396887665; Sun, 06 Dec 2015 02:14:47 -0800 (PST) Received: from proz.dclient.lsne.ch (85-218-12-53.dclient.lsne.ch. [85.218.12.53]) by smtp.gmail.com with ESMTPSA id pc2sm15789246wjb.11.2015.12.06.02.14.46 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Dec 2015 02:14:46 -0800 (PST) To: "tls@ietf.org" From: Bryan A Ford X-Enigmail-Draft-Status: N1110 Message-ID: <56640AAE.3040708@gmail.com> Date: Sun, 6 Dec 2015 11:15:10 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000900040802020609030505" Archived-At: Subject: [TLS] Simpler encrypted headers for DTLS (and TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 10:14:51 -0000 This is a cryptographically signed message in MIME format. --------------ms000900040802020609030505 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable While I think the approach I suggested for encrypted DTLS headers would work, it does have the downsides of (a) the complexity of managing the hash table of encrypted sequence numbers, and (b) the risk of desynchronization after long bursts of missed packets. But further discussion with Philipp Jovanovic led me to the realization that the simplest and cleanest solution in the DTLS case would simply be to rely on AEAD ciphers that either support "secret message numbers" or have a "misuse-resistance" property. In particular: - Secret message numbers basically do "precisely what DTLS needs", namely allow a message/record/sequence number to be transmitted under encryption along with the AEAD payload. Secret message numbers are specified as an optional feature for AEAD submissions to the ongoing CAESAR cipher competition (see http://competitions.cr.yp.to/caesar-call.html), and further elaborated in this useful message by DJB in 2013: https://groups.google.com/forum/#!searchin/crypto-competitions/secret$20= message$20numbers/crypto-competitions/n5ECGwYr6Vk/bsEfPWqSAU4J - Another optional feature that some CAESAR competition submissions have, and *all* are required to document one way or another, is "misuse-resistance". In particular, a misuse-resistant AEAD does not rely on nonce uniqueness for security. With a misuse-resistant AEAD (which we might alternatively just refer to as a "nonceless AEAD"), you can simply move the complete DTLS header from the additional_data field into the plaintext, and leave the sequence number out of the nonce. The sequence number will still be in (encrypted) header and thus available for replay-protection purposes and such, and will automatically ensure that all DTLS plaintexts (and hence all resulting ciphertexts) are cryptographically unique. I'm not proposing necessarily that the "next version of DTLS" (presumably based on TLS 1.3) should *only* allow AEADs that support secret message numbers or misuse-resistance. Rather, I'm proposing that the next DTLS should support at least one such cipher, and that when DTLS negotiates such a cipher, it simply takes advantage of the relevant property to move the DTLS header under encryption. So the upshot is that simply "using relevant AEAD features when available" would seem to take care of the DTLS case completely, with no special fuss or additional complexity. Which means that we can focus on the TLS case now, without worrying about whether and how easily it will translate to DTLS. And given that, for the TLS case I'm inclined to prefer my second proposal, namely just reinterpreting the "length" field to be a "next-record-length" field. This requires no special mucking with the AEAD in TLS either, and no extra complexity at all in TLS implementations that pad to constant record sizes (which I hope many will= ). For reference, some background pointers misuse-resistant ciphers (definitely not comprehensive): - https://eprint.iacr.org/2006/221.pdf - https://eprint.iacr.org/2015/999.pdf Cheers Bryan --------------ms000900040802020609030505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwNjEwMTUxMFowLwYJKoZIhvcNAQkEMSIEINRttKkTYC4dyeim1+WIKzt9GiPivZaUSy5A U8pYnby9MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBAJDfp3HYSDF7FKy9 oQHyM74VyO1w1Ovrqj/1UrjGUS0Fk9MQUxGPkqTR3Tubi6Jjylo+dkPIgb6Uf8uGBsa+dTi2 8TlSPzCMrm6IUMPv3XTmDLIT9nAq3Lx8EhZxHFiFQsn5RRIYFCdoCZClkmXR61RHDVl08td8 xSr6kWT4DlOYlrIxPwWKbPOQmdUmrWuIW0ceLzHNWm7b4a57ay2AWK/rqIqxveTEttqkvBgg onHd/52/0CmybgUv+58m8zG43B/pDqHGDJCG6XPUa6RKiKdMCWKsZNKsXJ5IfsCzS8Z8RV5V BUuauGf1veTI+xWH1e+eQ0FdyORMvn0eQTgI2SoAAAAAAAA= --------------ms000900040802020609030505-- From nobody Sun Dec 6 04:15:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FEA1B32CF for ; Sun, 6 Dec 2015 04:15:16 -0800 (PST) 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 zYaHO8DRCt4Z for ; Sun, 6 Dec 2015 04:15:15 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99C411B32CE for ; Sun, 6 Dec 2015 04:15:15 -0800 (PST) Received: by ykdv3 with SMTP id v3so168228867ykd.0 for ; Sun, 06 Dec 2015 04:15:15 -0800 (PST) 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=GczYmFFojMeZ7I+erafu3hsCxTfL+ID2pfnvybRMiC8=; b=q+rJPp7527Mka9rrm5Hx9zjBkda115ZAltivNMljjDLiMjrclKgw2u17ckXkEx75M/ HKStHa72Pl6/2SmzpktSWonO82q2BWjMv1QuoOJDHT/WpEgxYsYco9Eunpt1sP3xfZFj prPhMmB/40YHuvX1nA9dWjrVx2lGLjjs0JyS7wSFbOqqz5HqQPWuMancfwFCMy1W2LZe ImhS0qR6/UsPZo/7kQ4ICHFk2pCM34kJSUs7CA8/Eg7hl3p6qVF1zxR3f0yWh+dwjo2S J53dYf7/APtQThwWxRwIuG4FXc2TmwA1YjJb/0yrxkVcGv4gdteQsVjBEiohTpc9BiAR 8/hg== MIME-Version: 1.0 X-Received: by 10.129.57.135 with SMTP id g129mr17061881ywa.244.1449404114974; Sun, 06 Dec 2015 04:15:14 -0800 (PST) Received: by 10.129.148.131 with HTTP; Sun, 6 Dec 2015 04:15:14 -0800 (PST) In-Reply-To: <8DCA2D60-443F-41C1-82A2-294FD16D15D7@gmail.com> References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <2977428.j4DNTR9LXR@pintsize.usersys.redhat.com> <20151016203610.GA5596@roeckx.be> <2348468.lpGyMim7ub@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B3DA@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9B509@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9B5C9@uxcn10-5.UoA.auckland.ac.nz> <8DCA2D60-443F-41C1-82A2-294FD16D15D7@gmail.com> Date: Sun, 6 Dec 2015 07:15:14 -0500 Message-ID: From: Watson Ladd To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 12:15:17 -0000 On Sun, Dec 6, 2015 at 1:59 AM, Yoav Nir wrote: > >> On 6 Dec 2015, at 4:44 AM, Watson Ladd wrote: >> >> If you disagree, please cite the sentence of the TLS >> RFC which prohibits accepting application data records during the >> handshake. > > OK, I=E2=80=99ll bite. Top of page 36: > > Client Server > > ClientHello --------> > ServerHello > Certificate* > ServerKeyExchange* > CertificateRequest* > <-------- ServerHelloDone > Certificate* > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > Finished --------> > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data > > Figure 1. Message flow for a full handshake > > > See? Application data goes *after* the Finished message. Not between Cli= entHello and anything else. Now this swim track diagram may not look like a= formal definition, but RFCs are written to be processed by humans, not com= puters. If I add some application data in the middle there like this: (Ever meet a tax lawyer?) But is it defining the flow of messages in the Handshake protocol, or on the wire? The reason I think it's the first is that the RFC several times explains that different layers above the record layer are independent. Even if that's prohibited, there is no requirement to send an alert if that happens: allowing it is not prohibited. In fact several emails in this thread show that other implementers agree with my reading, and that there exist implementations that have this behavior. I hope that whatever renegotiation replacement we have in TLS 1.3 explicitly specifies that this sort of trick is allowed. > > Client Server > > ClientHello --------> > ServerHello > Certificate* > ServerKeyExchange* > CertificateRequest* > <-------- ServerHelloDone > Application Data > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > Finished --------> > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data > > > Any human can see that this is not the same as what=E2=80=99s in Figure 1= , and thus is wrong. We don=E2=80=99t need the RFC to provide a regular exp= ression or a state machine diagram to figure that out. > > Yoav > > > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sun Dec 6 05:08:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B8F1B3355 for ; Sun, 6 Dec 2015 05:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 8Ya2zHy0zvd3 for ; Sun, 6 Dec 2015 05:08:12 -0800 (PST) Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (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 4E3051B3354 for ; Sun, 6 Dec 2015 05:08:12 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 36A70A8A0432; Sun, 6 Dec 2015 13:08:09 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 0F9181FE0573; Sun, 6 Dec 2015 14:08:09 +0100 (CET) Date: Sun, 6 Dec 2015 14:08:08 +0100 From: Kurt Roeckx To: Peter Gutmann Message-ID: <20151206130808.GA5993@roeckx.be> References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <2977428.j4DNTR9LXR@pintsize.usersys.redhat.com> <20151016203610.GA5596@roeckx.be> <2348468.lpGyMim7ub@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B3DA@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4B9B509@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B9B509@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 13:08:14 -0000 On Sun, Dec 06, 2015 at 01:18:51AM +0000, Peter Gutmann wrote: > > I hadn't even thought it through to that point, more that you're not supposed > to accept anything between Client Hello and Client Keyex except an optional > Client Certificate. Please read the start of the thread, that includes relevant RFC sections that seem to indicate you can do this. Kurt From nobody Sun Dec 6 06:46:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84361A86DD for ; Sun, 6 Dec 2015 06:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 baS5uaiHM9bS for ; Sun, 6 Dec 2015 06:46:10 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2D28D1A8033 for ; Sun, 6 Dec 2015 06:46:09 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 685484242A2; Sun, 6 Dec 2015 14:46:08 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 4EA6742427F; Sun, 6 Dec 2015 14:46:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1449413168; bh=K1Osrr49sdxByHWGTUVI8XmdaaP8fTC1g/WwolHNb1o=; l=190; h=From:To:CC:Date:References:In-Reply-To:From; b=Fpl3ilm//NdrnAYB5ZxpZ9dMjrMEplgyDeWdWbfHBSaNpWnCs0p0OsNuBYd82ny7x iDEA8trxXc+G4aXDDzc35FOjzrFl+hRhkqsVqa/9D37/o7au2qv0rXrNkHLc3FVr5R +0+cXZO3WYPqQ19ZzdzLHhoGMyl3oL485yjwt3v4= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 4B73D2046; Sun, 6 Dec 2015 14:46:08 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sun, 6 Dec 2015 09:46:07 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Sun, 6 Dec 2015 09:46:07 -0500 From: "Salz, Rich" To: Eric Rescorla Thread-Topic: [TLS] Encrypted SNI Thread-Index: AQHRL4uDpc0zH797cEKmUXkuJX2tg569MnbAgABxhwCAAGZ9gA== Date: Sun, 6 Dec 2015 14:46:07 +0000 Message-ID: <7c34bff9bf1d4d9897802a6e98cfedb0@usma1ex-dag1mb1.msg.corp.akamai.com> References: <36a3b8e463f444ec9fd10c552ce702c4@usma1ex-dag1mb1.msg.corp.akamai.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: [172.19.36.82] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 14:46:11 -0000 PiBJJ20gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSBkZXNpZ24geW91J3JlIHN1Z2dlc3Rpbmcu DQoNCkRvZXMgdGhlIEVuY3J5cHRlZEV4dGVuc2lvbnMgY29udGFpbiB0aGUgZW50aXJlIGhlbGxv IGZvciB0aGUgIm5leHQgaG9wIj8NCg== From nobody Sun Dec 6 06:50:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F731A8715 for ; Sun, 6 Dec 2015 06:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.511 X-Spam-Level: X-Spam-Status: No, score=0.511 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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, T_RP_MATCHES_RCVD=-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 x9_Z2HamdugM for ; Sun, 6 Dec 2015 06:50:05 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395171A1BF1 for ; Sun, 6 Dec 2015 06:50:05 -0800 (PST) Received: by ioc74 with SMTP id 74so158574851ioc.2 for ; Sun, 06 Dec 2015 06:50:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YWMxBoCX1lKh2EALyxkuI0/L5EapIh7eE97ykmQdDmU=; b=JJmB+F28BdtOA1Lq8cCeT6sl0nxVIwmzY+j4JGBd4TARfDQSkFPu1p8K9aeM0Z4X4B DuJR8X/qJkt/LoOwTxG71/sBGycXp2a6TYXZ576ytQJ/EgCPcaIwBKu3LdE/PsWKycjv TAnLi2H0olDc6ocCrcmIpDhSo23/vH3d9XZxNgZXjUWu8JqYbYBSV1oS1ixJS5H6hE0A tSWVRXysgOWDqqzpYCUF4k/Cl2tAn9FiUtZt2IYYuEveyE+3hykih3qxTH9d4tGiwnP/ jq+w/8VRgMp63IVi9b9oOJnPr7hOlj5xoZ7TVBmnR9qkqwC/RC9ZceDW2+JdgaAknZEt Wo0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=YWMxBoCX1lKh2EALyxkuI0/L5EapIh7eE97ykmQdDmU=; b=jCnJrlcW9UZU6J93IFcj6zDegwaPmbSLOYlVgihgvtbOCUS30Mw3UgSvVsDpllyfNC Jck+whQWbt6JYhXs78GrxJxcxfu+0Lzcd9xkKNQ3kOhKJuZMKbqeAoi77/qb45Is9+Wq C5DgN4bSiJgKYnUFX/QGhOHO5iplJA7+2CeONBXTx6nsbRmfFsZNz+IyU1lAuOXVPcvv I2HUjHpoaD//dPVJSqxjxi1Ew5Kp41371h0L30usBPVdZnOvy0bPRb0Mel6s+N1FlLgm uB7Ir82TuXAziFcwx6TXX8T0str+oFL9gUeILoLI0xzH1d9TYqy3NgAB0Z8HdpRRLy9n EevA== X-Gm-Message-State: ALoCoQmhFGHtFizut0ei9ygE+OQpnkjnplWmJf80izDSuDb4BrJT9N2rZqWTZtEeXb04medRLotp MIME-Version: 1.0 X-Received: by 10.107.152.133 with SMTP id a127mr22971683ioe.60.1449413404375; Sun, 06 Dec 2015 06:50:04 -0800 (PST) Received: by 10.107.173.15 with HTTP; Sun, 6 Dec 2015 06:50:04 -0800 (PST) Date: Sun, 6 Dec 2015 06:50:04 -0800 Message-ID: From: Bill Cox To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1140e69e1a1fa505263bdb0e Archived-At: Subject: [TLS] Forward secrecy with resumption, and 0-RTT security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 14:50:07 -0000 --001a1140e69e1a1fa505263bdb0e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable AFAIK, there has never been a session resumed with forward secrecy. Is this correct? In the past, there were two cases: resumption using session IDs, and resumption with session tickets. Using session IDs loses forward secrecy, because the server always has session keys in a session cache, which could be used to decrypt the prior sessions. Using tickets did not work either, because the server always kept a ticket decryption key which could be used to decrypt all resumed sessions since the key was last rotated. My first question is: Do we care? The original definition of forward secrecy seemed to mean forward secrecy for all sessions older than the key rotation interval. This is what Twitter had when claiming support for forward secrecy. Do I understand this correctly? However, the new definition we seem to be using now is that no past session can be decrypted using server-side state that persists after the connection ends. Under this definition, AFAIK, there has never been a resumable session with forward secrecy. Is this definition taking forward secrecy too far? To have forward secrecy under the strict definition using the new PSK scheme, we need to use what the new name implies: pre _shared_ keys. The new name implies that the server remembers a unique shared key for the connection, which is server-side state per resumable connection. If we only store the PSK in the ticket, and go stateless on the server, then the server-side ticket decryption key again defeats strict forward secrecy. With a remembered server-side pre-shared secret, we can have a 0-RTT resume with strict forward secrecy. Is this already implied in the spec? If so, the spec could be improved, by stating this explicitly. However, the current statement that 0-RTT does not provide forward secrecy seems to be wrong in the case that we resume a 0-RTT connections with a server-remembered PSK. To have strict forward secrecy, given that the server already has to have server-side state (the pre-shared key), I find the old session ID scheme more palatable than the new tickets. The main point of session tickets was to eliminate the server-side session cache, wasn't it? I think the current spec does not describe well enough how to implement secure 0-RTT infrastructure. Instead, it seems to recommend against using 0-RTT, with a pretty dire warning about the insecurity of 0-RTT. I think that nearly the entire world will switch to 0-RTT, regardless of security limitations and warnings. Companies won=E2=80=99t be able to resist the im= proved connection time. IMO, the spec should describe how to address the security issues with 0-RTT, rather than just warning about security issues. So, here are my dumb thoughts about practical 0-RTT security infrastructure... One way is to bind resumption to orbits, by having only the orbit that issues a PSK remember the secret key. Something like this is needed in any case to provide 0-RTT replay protection. Without at least orbit-based replay protection, I think it does not make sense to allow a ClientVerify in a 0-RTT connection. There was a TODO in the last version I read asking what the client would sign in a 0-RTT ClientVerify. If orbit-based replay protection is in place using PSKs, then signing anything that identifies what PSK to use is enough. However, the handshake has to somehow be bound to the orbit to prevent the signature from being replayed in a MitM attack. Having a ticket that can only be decrypted using the orbit-specific ticket decryption key would work. Using a source address token bound to the orbit would also work. Signing the server Finish is not required to insure the signature will only be accepted once. There are two parts to a proof-of-possession: uniqueness and freshness. Uniqueness can be had using orbit-bound PSKs. Insuring freshness is harder. This could be done by adding timestamps to the material signed. With this, we would not get a complete proof of possession, because an attacker can attack the client's clock, unlike a normal proof of possession. However, if steps are taken to secure clocks, which is needed for TLS in any case, then we can get what I think of as "compelling evidence" of possession, which might be good enough. I think I've partially covered all three security concerns listed for 0-RTT connections: forward secrecy, replay protection, and client certs. The limitations seem to be: - 0-RTT resumption using PSK can address all 3, but not 0-RTT connections - Strict forward secrecy requires server-side state, so why are we using tickets? - Replay protection based on orbits is only partial protection - ClientVerify can only provide =E2=80=9Ccompelling evidence=E2=80=9D, rat= her than proof of possession It concerns me that the TLS 1.3 spec seems to say "Don't use 0-RTT! It's not secure!" when it is clear that the world will go in that direction. I would feel a lot better if the spec had more discussion about how to do 0-RTT securely. Thoughts? Bill --001a1140e69e1a1fa505263bdb0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

AFAIK, there has never been a session re= sumed with forward secrecy.=C2=A0 Is this correct?


In the past, there were two case= s: resumption using session IDs, and resumption with session tickets.=C2=A0= Using session IDs loses forward secrecy, because the server always has ses= sion keys in a session cache, which could be used to decrypt the prior sess= ions.=C2=A0 Using tickets did not work either, because the server always ke= pt a ticket decryption key which could be used to decrypt all resumed sessi= ons since the key was last rotated.


My first question is: Do we care?

The original definiti= on of forward secrecy seemed to mean forward secrecy for all sessions older= than the key rotation interval.=C2=A0 This is what Twitter had when claimi= ng support for forward secrecy.=C2=A0 Do I understand this correctly?=C2=A0= However, the new definition we seem to be using now is that no past sessio= n can be decrypted using server-side state that persists after the connecti= on ends.=C2=A0 Under this definition, AFAIK, there has never been a resumab= le session with forward secrecy.=C2=A0 Is this definition taking forward se= crecy too far?


To have forward secrecy under the strict definition using the new PS= K scheme, we need to use what the new name implies: pre _shared_ keys.=C2= =A0 The new name implies that the server remembers a unique shared key for = the connection, which is server-side state per resumable connection.=C2=A0 = If we only store the PSK in the ticket, and go stateless on the server, the= n the server-side ticket decryption key again defeats strict forward secrec= y.=C2=A0 With a remembered server-side pre-shared secret, we can have a 0-R= TT resume with strict forward secrecy.=C2=A0 Is this already implied in the= spec?=C2=A0 If so, the spec could be improved, by stating this explicitly.= =C2=A0 However, the current statement that 0-RTT does not provide forward s= ecrecy seems to be wrong in the case that we resume a 0-RTT connections wit= h a server-remembered PSK.


To have strict forward secrecy, given that the server al= ready has to have server-side state (the pre-shared key), I find the old se= ssion ID scheme more palatable than the new tickets.=C2=A0 The main point o= f session tickets was to eliminate the server-side session cache, wasn'= t it?


I = think the current spec does not describe well enough how to implement secur= e 0-RTT infrastructure.=C2=A0 Instead, it seems to recommend against using = 0-RTT, with a pretty dire warning about the insecurity of 0-RTT.=C2=A0 I th= ink that nearly the entire world will switch to 0-RTT, regardless of securi= ty limitations and warnings.=C2=A0 Companies won=E2=80=99t be able to resis= t the improved connection time.=C2=A0 IMO, the spec should describe how to = address the security issues with 0-RTT, rather than just warning about secu= rity issues.


So, here are my dumb thoughts about practical 0-RTT security infrastru= cture...


One way is to bind resumption to orbits, by having only the orbit that iss= ues a PSK remember the secret key.=C2=A0 Something like this is needed in a= ny case to provide 0-RTT replay protection.=C2=A0 Without at least orbit-ba= sed replay protection, I think it does not make sense to allow a ClientVeri= fy in a 0-RTT connection.


There was a TODO in the last version I read asking what t= he client would sign in a 0-RTT ClientVerify.=C2=A0 If orbit-based replay p= rotection is in place using PSKs, then signing anything that identifies wha= t PSK to use is enough. However, the handshake has to somehow be bound to = the orbit to prevent the signature from being replayed in a MitM attack. H= aving a ticket that can only be decrypted using the orbit-specific ticket d= ecryption key would work. Using a source address token bound to the orbit = would also work.=C2=A0 Signing the server Finish is not required to insure = the signature will only be accepted once.


There are two parts to a proof-of-possess= ion: uniqueness and freshness.=C2=A0 Uniqueness can be had using orbit-boun= d PSKs.=C2=A0 Insuring freshness is harder.=C2=A0 This could be done by add= ing timestamps to the material signed.=C2=A0 With this, we would not get a = complete proof of possession, because an attacker can attack the client'= ;s clock, unlike a normal proof of possession.=C2=A0 However, if steps are = taken to secure clocks, which is needed for TLS in any case, then we can ge= t what I think of as "compelling evidence" of possession, which m= ight be good enough.


I think I've partially covered all three security concerns= listed for 0-RTT connections: forward secrecy, replay protection, and clie= nt certs.=C2=A0 The limitations seem to be:


  • 0-RTT resumption using= PSK can address all 3, but not 0-RTT connections

  • Strict forward secrecy requires server-side state, so why ar= e we using tickets?

  • Replay protection= based on orbits is only partial protection

  • ClientVerify can only provide =E2=80=9Ccompelling evidence=E2=80=9D,= rather than proof of possession


It concerns me that the TLS 1.3 spec see= ms to say "Don't use 0-RTT!=C2=A0 It's not secure!" when = it is clear that the world will go in that direction.=C2=A0 I would feel a = lot better if the spec had more discussion about how to do 0-RTT securely.<= /span>


Thoughts= ?

Bill

--001a1140e69e1a1fa505263bdb0e-- From nobody Sun Dec 6 06:50:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA3A1A8732 for ; Sun, 6 Dec 2015 06:50:33 -0800 (PST) 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, HTML_MESSAGE=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 Bu3EJyqjX6fO for ; Sun, 6 Dec 2015 06:50:32 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC851A8731 for ; Sun, 6 Dec 2015 06:50:32 -0800 (PST) Received: by ykdr82 with SMTP id r82so169880650ykd.3 for ; Sun, 06 Dec 2015 06:50:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Txwa3pGOGHQJDj5NJ0g4iwJEyKC320Gj8GBVy5qi3KQ=; b=Ki2XeezASVoyziyBX/ye3bSBmgQ91fndBboloKD0ZmZ8LQCI94tb6ZxVnHTjYphLlG lxfpynjJU9EJSe9Sty3yA7vHfORX6CZvcPiP+fROSZ0zyeVBnAK1845gaqlXC/BRqdPc m2an6sL79pv2PxizT5ShsSaKR6RP+2NFmEksRHy/4Wb/EB7cCSd+6h1l9LQq2azH8nkH x7/wDWpd5mB7mJOWffi3WtkdiJL2MJVRJvr8QREqHRxaOGRxlC2MrNljAndhJND95xuB MmqkHzsAgOTp+9z4a7a4Dv3WLi+U2mFE+FU7RPVs2LcUfKuN03x5aHcU/vUcvFfhVvxx sDog== 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=Txwa3pGOGHQJDj5NJ0g4iwJEyKC320Gj8GBVy5qi3KQ=; b=boovGY4tTX8zMMxzcES2Yk67E7wGVx3ZsmA4QaAw/pE0JFI6jsb3lS8zFf3EIt/gx0 vHk6WdTld0GSgtGlsEIFHY3pkyINez5TqJnNHNedkG4A52lE/Ll3c/eod1QlcummTwOP /t3aSHee8BFrJtd8Sb/8/mqoTU2dM/vbDYJNmo/BUYRMlVaHuSLbebBxkiyALn6sFtBC Gn83yGTC5PAvnfPXIvZ5bqsD5MkeFRkqzvCFivE0zLIOAd+cF81fvBocZYYKaw/ClXuq 1HJsjGW5+uiasiFPnUxHzcerP+XnHk7Kb31vRnz1b4cb9WRHG5od4ZHRsmO2aixUdUGd xDXw== X-Gm-Message-State: ALoCoQnDHgppVZKAJ7l+asp0dlhBuJj3TgKtJnR+PX2QchiJJOk8hO866SnFtXdgCIb+lZlqWFHN X-Received: by 10.129.73.198 with SMTP id w189mr20857307ywa.223.1449413431817; Sun, 06 Dec 2015 06:50:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Sun, 6 Dec 2015 06:49:52 -0800 (PST) In-Reply-To: <7c34bff9bf1d4d9897802a6e98cfedb0@usma1ex-dag1mb1.msg.corp.akamai.com> References: <36a3b8e463f444ec9fd10c552ce702c4@usma1ex-dag1mb1.msg.corp.akamai.com> <7c34bff9bf1d4d9897802a6e98cfedb0@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eric Rescorla Date: Sun, 6 Dec 2015 06:49:52 -0800 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a114dc814bca6b205263bdcf8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 14:50:33 -0000 --001a114dc814bca6b205263bdcf8 Content-Type: text/plain; charset=UTF-8 On Sun, Dec 6, 2015 at 6:46 AM, Salz, Rich wrote: > > I'm not sure I understand the design you're suggesting. > > Does the EncryptedExtensions contain the entire hello for the "next hop"? > No. It (at most) says "the stuff that is post-handshake is actually a ClientHello for the next hop". I.e., it's literally TLS in TLS. -Ekr --001a114dc814bca6b205263bdcf8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Dec 6, 2015 at 6:46 AM, Salz, Rich <rsalz@akamai.com> wrote:
> I'm= not sure I understand the design you're suggesting.

Does the EncryptedExtensions contain the entire hello for the "= next hop"?

No. It (at most) sa= ys "the stuff that is post-handshake is actually a ClientHello for the= next hop". I.e., it's literally TLS in TLS.

-Ekr


--001a114dc814bca6b205263bdcf8-- From nobody Sun Dec 6 07:13:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3381A9023 for ; Sun, 6 Dec 2015 07:13:17 -0800 (PST) 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, HTML_MESSAGE=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 KQpr1fb_1UT8 for ; Sun, 6 Dec 2015 07:13:16 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3441A9004 for ; Sun, 6 Dec 2015 07:13:15 -0800 (PST) Received: by ykdr82 with SMTP id r82so170195802ykd.3 for ; Sun, 06 Dec 2015 07:13:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=o5s0YtFseTHYOBcIr28TZq17udx6uAmlQAxwoKObwX0=; b=2DBzi54JoZtkJCnUR0puvIdLi0BLWZcxgYsRNNdtqKAjedYM4rD9d26W7DFclZJAxc ot3/61skXcRHBjTQBYY3ep/DVkFaghcfZ3+El0yfZCvvq8kca0HjOE5Kh4Hhy/y7cXmJ 64jgqY0CAtWafPpO53711nJRrG7TxNJBMB/jxX5IZ/cy9gkkz5v11sxxPjKY56HTZdl2 OJDN8cIZVFciEDCpsPevvT3Lrge6ZiE89vzGyRDRVnoXXUtXGNpoUerp1ezPYtlkvtnM id/7/PQR+XjmucfMCAXGovgbDLZRWBG4YhGtZqD5Z3wPOhuMYDEZdXcziq8XOwwQwCG7 0D4A== 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=o5s0YtFseTHYOBcIr28TZq17udx6uAmlQAxwoKObwX0=; b=aU7JnmuEFCso+d2sbxG+CwGZagFTd7y4FDJbxLpeoagVeH1ymNyz43iEkzKV4U4wr3 vGc0JrI/Hbgr5unJHiBuyCTiNpnrji08OVn+O/jETl1YzQ430whUiVulbaFQdRR4QpzR 0XOgc/MxquM+7Kt+V3KaKLNMStpmT+QLVF7Ncd6CRMzodFlppr7SvYy5NA3XtSArYYBX ChEYJ3tOC4s39u3rzrVqiOPAZdH3/TWFu3I+oocf/9dfP6Dm5z2TPNSs1eBC5dBDNclz fVHdU4ySALJ5EQe89QkKSTf0Xvxno3WsPpqcP38ZueXj+dCDjMORYSCBcrLi526/A/Ix w0MQ== X-Gm-Message-State: ALoCoQlhCZDvWoWld+D6fqN9LG/jH+JWAyoA9iDMI9aMICa2PsEh1/eYj8hacD4FWrhYcLnO8BwS X-Received: by 10.129.46.84 with SMTP id u81mr18275019ywu.129.1449414795121; Sun, 06 Dec 2015 07:13:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Sun, 6 Dec 2015 07:12:35 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sun, 6 Dec 2015 07:12:35 -0800 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a11409380ff049205263c2d0b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Forward secrecy with resumption, and 0-RTT security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 15:13:17 -0000 --001a11409380ff049205263c2d0b Content-Type: text/plain; charset=UTF-8 On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox wrote: > AFAIK, there has never been a session resumed with forward secrecy. Is > this correct? > Yes, session resumption does not have PFS. Though note that with 1.3 that will no longer be true, because you can do PSK-DHE. > In the past, there were two cases: resumption using session IDs, and > resumption with session tickets. Using session IDs loses forward secrecy, > because the server always has session keys in a session cache, which could > be used to decrypt the prior sessions. Using tickets did not work either, > because the server always kept a ticket decryption key which could be used > to decrypt all resumed sessions since the key was last rotated. > Well, the server could in principle delete the keys from the session cache and (at more cost) the decryption key But yes. > To have forward secrecy under the strict definition using the new PSK > scheme, we need to use what the new name implies: pre _shared_ keys. The > new name implies that the server remembers a unique shared key for the > connection, which is server-side state per resumable connection. If we > only store the PSK in the ticket, and go stateless on the server, then the > server-side ticket decryption key again defeats strict forward secrecy. > With a remembered server-side pre-shared secret, we can have a 0-RTT resume > with strict forward secrecy. Is this already implied in the spec? If so, > the spec could be improved, by stating this explicitly. However, the > current statement that 0-RTT does not provide forward secrecy seems to be > wrong in the case that we resume a 0-RTT connections with a > server-remembered PSK. > > To have strict forward secrecy, given that the server already has to have > server-side state (the pre-shared key), I find the old session ID scheme > more palatable than the new tickets. The main point of session tickets was > to eliminate the server-side session cache, wasn't it? > The current ticket scheme is compatible with either a server-side database *or* having self-contained tickets which are encrypted with a server-side key. (This was also true for tickets, it's just that you didn't bother with tickets if that is what you wanted). If you want a database, you just use an identifier as the key name. The point is to have a mechanism which accomodates either design. I think the current spec does not describe well enough how to implement > secure 0-RTT infrastructure. Instead, it seems to recommend against using > 0-RTT, with a pretty dire warning about the insecurity of 0-RTT. > Well, the primary purpose of this warning isn't to warn about PFS. It's really to warn about the replay issue, which is unique to 0-RTT and which can't really be fixed by proper implementation. The issue isn't that it's not possible to have anti-replay if you're willing to store server side state, but rather how you respond to server-side state loss. Moreover, the problems exist whether or not you use certificate-based client authentication. I haven't thought this through in as much detail as I've thought through the non-PSK 0-RTT case, but I don't believe that PSK-resumption solves the problems with replay. The basic issue is the same: what happens when a server gets a connection attached to state which it doesn't have. So, what the attacker would do duplicate the ClientHello + PSK and send one copy to the true datacenter and one to another datacenter that doesn't have state. The right datacenter will process the 0-RTT handshake and the wrong one will reject it, causing the client to fall back to 1-RTT and retransmit the request. So, you still get replay. -Ekr --001a11409380ff049205263c2d0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Dec 6, 2015 at 6:50 AM, Bill Cox <waywardgeek@google.com><= /span> wrote:

AFAIK, there has never been a session resumed with forward secrecy.= =C2=A0 Is this correct?


=
Yes, session resumption does not have PFS. Though note that with 1.3 t= hat will
no longer be true, because you can do PSK-DHE.


=C2=A0

In the past, t= here were two cases: resumption using session IDs, and resumption with sess= ion tickets.=C2=A0 Using session IDs loses forward secrecy, because the ser= ver always has session keys in a session cache, which could be used to decr= ypt the prior sessions.=C2=A0 Using tickets did not work either, because th= e server always kept a ticket decryption key which could be used to decrypt= all resumed sessions since the key was last rotated.


Well, the server could in principle dele= te the keys from the session cache and (at more
cost) the decrypt= ion key But yes.


=C2=A0

To have forward secrecy under the strict definition using the n= ew PSK scheme, we need to use what the new name implies: pre _shared_ keys.= =C2=A0 The new name implies that the server remembers a unique shared key f= or the connection, which is server-side state per resumable connection.=C2= =A0 If we only store the PSK in the ticket, and go stateless on the server,= then the server-side ticket decryption key again defeats strict forward se= crecy.=C2=A0 With a remembered server-side pre-shared secret, we can have a= 0-RTT resume with strict forward secrecy.=C2=A0 Is this already implied in= the spec?=C2=A0 If so, the spec could be improved, by stating this explici= tly.=C2=A0 However, the current statement that 0-RTT does not provide forwa= rd secrecy seems to be wrong in the case that we resume a 0-RTT connections= with a server-remembered PSK.


To have strict forward secrecy, given that the serve= r already has to have server-side state (the pre-shared key), I find the ol= d session ID scheme more palatable than the new tickets.=C2=A0 The main poi= nt of session tickets was to eliminate the server-side session cache, wasn&= #39;t it?


The curre= nt ticket scheme is compatible with either a server-side database *or* havi= ng self-contained
tickets which are encrypted with a server-side = key. (This was also true for tickets, it's just that
you didn= 't bother with tickets if that is what you wanted). If you want a datab= ase, you just use
an identifier as the key name. The point is to = have a mechanism which accomodates either
design.

<= /div>

I think the current spec does not des= cribe well enough how to implement secure 0-RTT infrastructure.=C2=A0 Inste= ad, it seems to recommend against using 0-RTT, with a pretty dire warning a= bout the insecurity of 0-RTT.


=
Well, the primary purpose of this warning isn't to warn abou= t PFS. It's really to warn
about the replay issue, which is u= nique to 0-RTT and which can't really be fixed
by proper impl= ementation. The issue isn't that it's not possible to have anti-rep= lay
if you're willing to store server side state, but rather = how you respond to server-side state
loss. Moreover, the problems= exist whether or not you use certificate-based
client authentica= tion.

I haven't thought this through in as muc= h detail as I've thought through the
non-PSK 0-RTT case, but = I don't believe that PSK-resumption solves the
problems with = replay. The basic issue is the same: what happens when
a server g= ets a connection attached to state which it doesn't have. So,
what the attacker would do duplicate the ClientHello + PSK and send one
copy to the true datacenter and one to another datacenter that does= n't have
state. The right datacenter will process the 0-RTT h= andshake and the
wrong one will reject it, causing the client to = fall back to 1-RTT and retransmit
the request. So, you still get = replay.

-Ekr


--001a11409380ff049205263c2d0b-- From nobody Sun Dec 6 07:50:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303691ACEDE for ; Sun, 6 Dec 2015 07:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-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 GCc68M4cXemi for ; Sun, 6 Dec 2015 07:50:39 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D97381ACED8 for ; Sun, 6 Dec 2015 07:50:39 -0800 (PST) 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 (Postfix) with ESMTPS id 2125DC0A8047; Sun, 6 Dec 2015 15:50:39 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-27.ams2.redhat.com [10.36.112.27]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB6FoYMZ012222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Dec 2015 10:50:38 -0500 From: Hubert Kario To: Peter Gutmann Date: Sun, 06 Dec 2015 16:50:28 +0100 Message-ID: <2024935.xrVgKcrptC@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.6-201.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B9B3DA@uxcn10-5.UoA.auckland.ac.nz> References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <2348468.lpGyMim7ub@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B3DA@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1617483.uhfFOxBrrD"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 15:50:41 -0000 --nextPart1617483.uhfFOxBrrD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Saturday 05 December 2015 23:54:25 Peter Gutmann wrote: > Hubert Kario writes: > >miTLS does accept Application Data when it is send between Client > >Hello and Client Key Exchange and rejects it when it is sent between= > >Change Cipher Spec and Finished. >=20 > Given that miTLS is a formally verified implementation, would this > imply that there's a problem with the verification? "Beware of bugs > in the above code; I have only proved it correct, not tried it"? This behaviour is dictated by the TLS 1.2 RFC, although partially=20 indirectly: - the acceptance of application data during subsequent handshakes is=20= explicit - the no application data between CCS and Finished is implicit, as it is only stated that the Finished MUST be the next message directly following CCS. And since CCS and Finished have different content=20 types, that means that the limitation is cross-content type, unlike=20= for other handshake messages So on the face of it, behaviour of miTLS is correct. Now, as we've discussed on the OpenSSL bug tracker. This does cause=20 problems if we have certificate based client authentication and the TLS= =20 library returns client authentication data from *new* handshake while i= t=20 still has not received and processed Finished message. If that is the=20= case, then the attacker may force the server to process messages under=20= authority it still didn't verify. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart1617483.uhfFOxBrrD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJWZFlEAAoJEJKo0bgB0vX1a3MP/0x2dcrG4t7iouvJIC3CgqVA ifciQseayeold500HpxaPgKomYjVNY80cciVtARBZyXHXaP/+v7yH7IgLlEy/Lhf gCzzKVHlDu4uiCB7Z0ToRPvhxtAOLlH3F7Ee1ZB6cfHmWyr/7LXBNORDjH7xxpAC AJZRW4UuPQfQIuzm/Se6HjkVAYiZ2BcjYPyS/13xtHMER1bFIB6Q4GIMSmaTntqc DVQTN8SHmZjW1IbxmgYkOm+Hm1Sq2GLSGpyJ5y/S4wBYFH4wVPyGNj45D6ypYWgW Bp0/f399YaL206BG1pUhndabSs1tbq57kVHX5wgbDjDaui7K6F16WZ7peAhEPqEP nNX48qbTI2wxJXBf4NV02HQZ4k9hRbvPU2sp87WetHLkZ2Ber/ptAVv73dcr4ZEB bqLEWv1b0QGuBDrtjzeZ2B/XWW07WV28H+2neX5ZNGAR4k4J6gGqUtFg3FzC40JE doLDLwaxwlDZu44Id9T14bUBzLai9p2oHZse/TYxPx126yfnrolY/ASNIS/amr6g a+D669mMY7T+A9e0k6MWgUUX+QaX+w23jkmidNpUd35ivjBZIp9V6SikzgVJWv2M FdDng/JEndk1NGrfoM34QumoNgLknXOcufsZqO54igCNSfU40MtbQWBAHtiQTnf8 fcMlY0lIXzFIL1XYywpB =AnyC -----END PGP SIGNATURE----- --nextPart1617483.uhfFOxBrrD-- From nobody Sun Dec 6 07:53:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709911ACEFC for ; Sun, 6 Dec 2015 07:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-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 8cUX3MEsH_wX for ; Sun, 6 Dec 2015 07:53:26 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74BF01ACEFB for ; Sun, 6 Dec 2015 07:53:26 -0800 (PST) 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 (Postfix) with ESMTPS id 3E7E04C501; Sun, 6 Dec 2015 15:53:26 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-27.ams2.redhat.com [10.36.112.27]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB6FrLR7013015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Dec 2015 10:53:25 -0500 From: Hubert Kario To: Watson Ladd Date: Sun, 06 Dec 2015 16:53:20 +0100 Message-ID: <21964299.nZSUBkleHH@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.6-201.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <9A043F3CF02CD34C8E74AC1594475C73F4B9B3DA@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2107086.hcYN7z1yDb"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 15:53:27 -0000 --nextPart2107086.hcYN7z1yDb Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Saturday 05 December 2015 19:20:11 Watson Ladd wrote: > On Sat, Dec 5, 2015 at 6:54 PM, Peter Gutmann=20 wrote: > > Hubert Kario writes: > >>miTLS does accept Application Data when it is send between Client > >>Hello and Client Key Exchange and rejects it when it is sent > >>between Change Cipher Spec and Finished. > >> > > Given that miTLS is a formally verified implementation, would this > > imply that there's a problem with the verification? "Beware of > > bugs in the above code; I have only proved it correct, not tried > > it"? >=20 > Are you saying there is a security flaw with the behavior described? > Because I don't believe there is after one adopts Extended Master > Secret. (Someone more familiar with the security should check this) Extended Master Secret doesn't come into play here at all. The attack=20= requires just a passive observation of a legitimate exchange for the=20= attacker to have enough information to fake its identity, provided that= =20 TLS library returns data to application from a new handshake in=20 renegotiation before the renegotiation finished. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart2107086.hcYN7z1yDb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJWZFnwAAoJEJKo0bgB0vX1580P/1luKu22MODq6xehsWptgCGZ S3J8UutIQb0t7Z+x7QlkiEcpV2ysEc1p2mtb56W/ig/c3EvR8CEcMPxoyK3zCUoK 1McmoMpKVnkKd5bydNT3otbezyt2yCObqYnWgaxIevhiHJEj9rW9LsJB1dz7fKOS Ip6LVHDi6IFG9DenFYbZKS77pDO1m5pyVgF5bFADUTg9lbM9ksIYuhP7C4U/dB6I +7fhuVGxCmgQ8VQgYMogtsSIxPVJ4YpThBv3T+AtP5b+bVnAySNzWehuMlAZ3JTF CDZu1FwD6qLMjI6FUJPKLdV+Y09pi8qQtVulRGhvZeoRjz/ufhm+ahTrfNwMopYe rF+ZxPj8WlLqM3NXylREVVFFL2VugqwS7CY01Ly3Ks9GS+cghGlhoPPGgmAi9agm w1uGFDLSvhsVPDiWDLA3MMb4iYaLB6X5lJlMP/boEBuzFCTgVFbNzXqwgqQiAo5I 27rFWn8ey7Wx1lGK9RH/fbKSrr+d9PxAh7SuW9yB6B2S9bNZl2RaZMLAgKDh1udo CQn36kLIPFKYnzcyMxNyHe43zZyew0ypIcae/4EzpJbzeFFX5XOXZkQZwO8ef/BE dkDQRvAARU5zL0jy2VF3wMa6ahPquCjvJYmqssEe03D+bMps9vYk1aImHRiALgnA wr/ejsvxX4rl1Vt/H13q =TeHh -----END PGP SIGNATURE----- --nextPart2107086.hcYN7z1yDb-- From nobody Sun Dec 6 08:05:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EF61AD063 for ; Sun, 6 Dec 2015 08:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, TVD_PH_BODY_ACCOUNTS_PRE=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 yoL82JZJ0QR2 for ; Sun, 6 Dec 2015 08:05:05 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7611E1AD062 for ; Sun, 6 Dec 2015 08:05:04 -0800 (PST) Received: by wmec201 with SMTP id c201so134432523wme.0 for ; Sun, 06 Dec 2015 08:05:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:mime-version:content-type:in-reply-to:date:cc :message-id:references:to; bh=DOnHK17lLiTt+BkStjY2ERmRnXXnvvAP5fEQ78Jz+2g=; b=JkH1tVO+RqW4GfEyKsYAcpFt0PcwQn6O2/Lb5LAPgsiQcUWmQldXpFguzZsXti2Srl Wyj0i4cM8Suo3hlF57jPO/Rhfkl5kGSvX10fhuqZ9/WO+OvEc8UrwplT67gi4bXdAIVT z/xk9xiV2114f94CDcIeU0IEzGmUoPU4gEDXgYvItBBRfT9zIzrc2S4rSts5w7c+fL5Y LOxiAgPhAymWp6C9cG07Ji04aZH9SUj6Di5pynm4x9dfyhuW7UJkAEkkYFWfVmXXXm+b zT8qYl8CVd2e15BqO+yr5XAHOXKUt0RUNYnR05b1sK3bzIYqiEk5g5RJgrZzFlpsfmCq tboA== X-Received: by 10.28.9.138 with SMTP id 132mr16112685wmj.19.1449417903102; Sun, 06 Dec 2015 08:05:03 -0800 (PST) Received: from [192.168.0.12] (89-156-8-219.rev.numericable.fr. [89.156.8.219]) by smtp.gmail.com with ESMTPSA id l7sm20913066wjx.14.2015.12.06.08.05.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 06 Dec 2015 08:05:02 -0800 (PST) From: Karthikeyan Bhargavan X-Google-Original-From: Karthikeyan Bhargavan Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CE96B18A-D604-4EAD-BFEC-675059A1E0EF"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 In-Reply-To: <2024935.xrVgKcrptC@pintsize.usersys.redhat.com> Date: Sun, 6 Dec 2015 17:04:59 +0100 Message-Id: <1DDA0CBD-4D73-43A4-A647-10ED73CE1A99@inria.fr> References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <2348468.lpGyMim7ub@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B3DA@uxcn10-5.UoA.auckland.ac.nz> <2024935.xrVgKcrptC@pintsize.usersys.redhat.com> To: Hubert Kario X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 16:05:07 -0000 --Apple-Mail=_CE96B18A-D604-4EAD-BFEC-675059A1E0EF Content-Type: multipart/alternative; boundary="Apple-Mail=_A0920F7F-6D5C-4DD9-A3DB-0F059ADE8C87" --Apple-Mail=_A0920F7F-6D5C-4DD9-A3DB-0F059ADE8C87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Our state machine design in miTLS was quite deliberate, and based on our = interpretation of the TLS 1.2 spec. It is possible that we got this = interpretation wrong, but maybe the protocol authors can clarify the = intended behavior. However, I think that looking at the Handshake protocol message sequence = (Figure 1) for guidance is misleading, because this sequence only = concerns the first handshake and does not handle renegotiation. = Otherwise, all messages would be marked as optionally encrypted. A = proper interpretation of this issue must take into account the two-layer = Record/Handshake split that is inherent to TLS 1.2. For example, one = interpretation is that the CCS message changes Record state and = Application Data can then directly interact with Record without = necessarily being aware of Handshake status. In any case, a note about the miTLS security theorem. In miTLS, every = application data fragment is labeled by the epoch in which it is sent = and received. miTLS itself does not concatenate data from different = epochs, but gives applications enough information about the two epochs = so that it can choose to combine data from different epochs (say if the = certificates used in the two epochs are the same.) So, the miTLS security theorem shows that sending and accepting data = during a renegotiation handshake is fine, as long as: (a) this data is treated as belonging to the previous epoch, not the = next one, and (b) no data is sent or accepted between CCS and Finished in either = direction. Notably, this means that if the new epoch uses new certificates for the = client and/or server, any application data sent during the handshake = does not get to be authorized with the new certificates, since it still = belongs to the old epoch. If the current handshake completes and then = new data is sent, the new data will be labeled with the new epoch. Now, = the application on top of TLS gets to decide whether it wants to = concatenate the data streams from the two epochs. For other implementations, I do agree that sending or accepting data = once renegotiation has begun but before the new handshake has finished = can be dangerous, because it is sometimes unclear whether this data will = be associated with the as-yet-unconfirmed parameters of the new = handshake. Best, -K. > On 06 Dec 2015, at 16:50, Hubert Kario wrote: >=20 > On Saturday 05 December 2015 23:54:25 Peter Gutmann wrote: >> Hubert Kario writes: >>> miTLS does accept Application Data when it is send between Client >>> Hello and Client Key Exchange and rejects it when it is sent between >>> Change Cipher Spec and Finished. >>=20 >> Given that miTLS is a formally verified implementation, would this >> imply that there's a problem with the verification? "Beware of bugs >> in the above code; I have only proved it correct, not tried it"? >=20 > This behaviour is dictated by the TLS 1.2 RFC, although partially > indirectly: > - the acceptance of application data during subsequent handshakes is > explicit > - the no application data between CCS and Finished is implicit, as it > is only stated that the Finished MUST be the next message directly > following CCS. And since CCS and Finished have different content > types, that means that the limitation is cross-content type, unlike > for other handshake messages >=20 > So on the face of it, behaviour of miTLS is correct. >=20 > Now, as we've discussed on the OpenSSL bug tracker. This does cause > problems if we have certificate based client authentication and the = TLS > library returns client authentication data from *new* handshake while = it > still has not received and processed Finished message. If that is the > case, then the attacker may force the server to process messages under > authority it still didn't verify. >=20 > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech = Republic_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_A0920F7F-6D5C-4DD9-A3DB-0F059ADE8C87 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Our state = machine design in miTLS was quite deliberate, and based on our = interpretation of the TLS 1.2 spec. It is possible that we got this = interpretation wrong, but maybe the protocol authors can clarify the = intended behavior.
However, = I think that looking at the Handshake protocol message sequence (Figure = 1) for guidance is misleading, because this sequence only concerns the = first handshake and does not handle renegotiation. Otherwise, all = messages would be marked as optionally encrypted. A proper = interpretation of this issue must take into account the two-layer = Record/Handshake split that is inherent to TLS 1.2. For example, one = interpretation is that the CCS message changes Record state and = Application Data can then directly interact with Record without = necessarily being aware of Handshake status.

In any case, a note about the = miTLS security theorem. In miTLS, every application data fragment is = labeled by the epoch in which it is sent and received. miTLS itself does = not concatenate data from different epochs, but gives applications = enough information about the two epochs so that it can choose to combine = data from different epochs (say if the  certificates used in the = two epochs are the same.)

So, the miTLS security theorem shows that sending and = accepting data during a renegotiation handshake is fine, as long = as:
(a) this data is = treated as belonging to the previous epoch, not the next one, = and 
(b) no = data is sent or accepted between CCS and Finished in either = direction.
Notably, = this means that if the new epoch uses new certificates for the client = and/or server, any application data sent during the handshake does not = get to be authorized with the new certificates, since it still belongs = to the old epoch. If the current handshake completes and then new data = is sent, the new data will be labeled with the new epoch. Now, the = application on top of TLS gets to decide whether it wants to concatenate = the data streams from the two epochs. 

For other implementations, I do agree that sending = or accepting data once renegotiation has begun but before the new = handshake has finished can be dangerous, because it is sometimes unclear = whether this data will be associated with the as-yet-unconfirmed = parameters of the new handshake.

Best,
-K.



On 06 Dec = 2015, at 16:50, Hubert Kario <hkario@redhat.com> wrote:

On Saturday 05 = December 2015 23:54:25 Peter Gutmann wrote:
Hubert Kario = <hkario@redhat.com> writes:
miTLS does accept Application Data when it is send between = Client
Hello and = Client Key Exchange and rejects it when it is sent between
Change Cipher Spec and = Finished.

Given that miTLS is a formally verified implementation, would = this
imply that = there's a problem with the verification?  "Beware of bugs
in the above code; I have only = proved it correct, not tried it"?

This behaviour is dictated by = the TLS 1.2 RFC, although partially 
indirectly:
- the acceptance of application data during = subsequent handshakes is 
  explicit
- the no application data between CCS and Finished is = implicit, as it
 = is only stated that the Finished MUST be the next message = directly
  = following CCS. And since CCS and Finished have different = content 
  = types, that means that the limitation is cross-content type, = unlike 
  = for other handshake messages

So on the face of it, behaviour of miTLS is = correct.

Now, as = we've discussed on the OpenSSL bug tracker. This does = cause 
problems = if we have certificate based client authentication and the = TLS 
library = returns client authentication data from *new* handshake while = it 
still has = not received and processed Finished message. If that is = the 
case, then = the attacker may force the server to process messages = under 
authority = it still didn't verify.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, = Brno, Czech = Republic_______________________________________________
TLS mailing list
TLS@ietf.org
=

= --Apple-Mail=_A0920F7F-6D5C-4DD9-A3DB-0F059ADE8C87-- --Apple-Mail=_CE96B18A-D604-4EAD-BFEC-675059A1E0EF 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 iQEbBAEBCgAGBQJWZFyrAAoJEB/WSo9veuUKYF8H+JVDbpaGV0zMOU3gO5tQc8GL NDkIXX1goKTmfxvplbIqvl/fVuhRnTnv5yU0qqTQppu8vsyfQyfidzVhkBafIlsl p6K3QZaESjkg8Rc6CFlMCCy12SRq9hczmXh7RsxBgRTE2yHyN2lgItlBtUJ0k9gE YxnVLYHEQo1oD4Vr7gujhulxIwO9lBi4fAA9KV7yf/jHoum6gNvdSMrFar4feAGB 7+6gD2o7VoywUsuasDjeMa2/G9YpER5bjRrgjjHhxZxNL+J2hK8dDYnhkEaNwHld SgUGF1c8qk4TxG6AiOdoZb+C16qYSqqc9WRU9jGDSuiCIz3P08qy5JH6dek1ew== =W9ir -----END PGP SIGNATURE----- --Apple-Mail=_CE96B18A-D604-4EAD-BFEC-675059A1E0EF-- From nobody Sun Dec 6 08:05:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B071AD05D for ; Sun, 6 Dec 2015 08:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-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 1_WLgs-MrxhM for ; Sun, 6 Dec 2015 08:05:06 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 702571AD060 for ; Sun, 6 Dec 2015 08:05:06 -0800 (PST) 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 (Postfix) with ESMTPS id 0DBD98EFD7; Sun, 6 Dec 2015 16:05:06 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-27.ams2.redhat.com [10.36.112.27]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB6G51bj014760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Dec 2015 11:05:05 -0500 From: Hubert Kario To: Peter Gutmann Date: Sun, 06 Dec 2015 17:05 +0100 Message-ID: <2044866.XHY5TnXfS8@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.6-201.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B9B61C@uxcn10-5.UoA.auckland.ac.nz> References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <9A043F3CF02CD34C8E74AC1594475C73F4B9B61C@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart15422772.NS7PSBb4lZ"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 16:05:07 -0000 --nextPart15422772.NS7PSBb4lZ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Sunday 06 December 2015 02:48:33 Peter Gutmann wrote: > Watson Ladd writes: > >please cite the sentence of the TLS RFC which prohibits accepting > >application data records during the handshake. > > Please cite the sentence of the TLS RFC which prohibits accepting SSH= > messages during the handshake. > > Please cite the sentence of the TLS RFC which prohibits executing > /usr/games/hack during the handshake. >=20 > Please cite the sentence of the TLS RFC which prohibits reformatting > the user's hard drive during the handshake. >=20 > (This debate is pointless and probably annoying everyone else, so I'l= l > bow out now). Peter, I think you should go back to the beginning of the thread. (I'm sorry for the necromancy making it a bit hard, but there was a=20 direct question aimed at me that I didn't have time to answer earlier=20= and I don't think we arrived at conclusion before) To summarise: RFC 5246 Section 6.2.1 states: Recipients MUST receive and process interleaved application layer traffic during handshakes subsequent to the first one on a connection. At the same time, sections like 7.4.7 state: It [Client Key Exchange message] MUST immediately follow the client certificate message, if it is sent. or, at section 7.4.9: A Finished message is always sent immediately after a change cipher spec message The question is, which one takes precedence? =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart15422772.NS7PSBb4lZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJWZFysAAoJEJKo0bgB0vX1q8kQAJMh8Oq4BR/OcjW+gXLr0Ycr pvNqP6CMmBTpaPPbMW051oYjW0EtlDLBOYtLAghU/hCKa6IkK2QRrEyi9JxFCfAl 8qm7TTknnclV55zV09pxyDKtNO57IB5GcSOpXJyT/bdpKRRKV3UnIIYpe9rfNEBl 4G8W/JZeu7Km2BK9t8PQCqk6WSx443M6kuP4XpdGipWb5jUWOF/oSKH+nh+quH0+ 4vULoo1l4JZg6Fqr8BpsovNdb4ZIt+yWYr8SKAoyZlZlK/87/yv7r7Qxn8+9bHIN V9aBqRWe3wTCm7WlmbKV/x8asHSG9Rsk00fSyc4VYR6FajhsdmculMtLQD7askSQ jo/lTTHhwmmr3EpdCHGOuJeVF3YrZ1Uwcs6kyck08ft4baBE9hUYQkBySu/PDN3d lYRg3tJeDX4muOwan9DrObAqc7EmQpGWcx8OvOmAIBYixn8JfW8K8rB45Dh/wFBp qaYgwnnARbI79rgFZnOE8GxF4rVYLxUOgg5kVRGWzbDfqlNLQSWzwkqWGw47B/yb 0mmfCXGn3ro7NQ3byMZ28IBUp8kTKVkONqDrHuY6SWhmwhZHoyFYplnWShvme+Ik SlDb86Kj4BoEX+JFlz916BZjI5G3cKOcUYNo8cJr9wJT+qcO1V0xvC3kqtdWzdcX SzVvEA7uCpdsKKD25gLr =Mak4 -----END PGP SIGNATURE----- --nextPart15422772.NS7PSBb4lZ-- From nobody Sun Dec 6 08:09:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251131AD06E for ; Sun, 6 Dec 2015 08:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-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 9vLrxCynmcTN for ; Sun, 6 Dec 2015 08:09:15 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EAFE1AD06B for ; Sun, 6 Dec 2015 08:09:15 -0800 (PST) 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 (Postfix) with ESMTPS id 091238F28B; Sun, 6 Dec 2015 16:09:15 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-27.ams2.redhat.com [10.36.112.27]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB6G9AtB006757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Dec 2015 11:09:14 -0500 From: Hubert Kario To: Peter Gutmann Date: Sun, 06 Dec 2015 17:09:09 +0100 Message-ID: <4144627.kvfJsuCCBo@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.6-201.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B9B5C9@uxcn10-5.UoA.auckland.ac.nz> References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <9A043F3CF02CD34C8E74AC1594475C73F4B9B5C9@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2890720.IdmipqFpt4"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 16:09:16 -0000 --nextPart2890720.IdmipqFpt4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Sunday 06 December 2015 02:33:39 Peter Gutmann wrote: > > No matter how you colour it, accepting > Application Data after a Client Hello is wrong. Is there any random,= > non-formally-verified implementation that would do that? The discussion is about renegotiated handshakes, and yes there is one. Java implementation of TLS can send Application Data during subsequent=20= handshakes. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart2890720.IdmipqFpt4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJWZF2lAAoJEJKo0bgB0vX14fYP/ArxY83nmKLoHCtP7hc4xvRf NDlbdiHAQJmSci+5nTVD4ThLbkkltsjnpImgLYhvhlpa49307JJC+KGkCup3THYy WEMtTl70agbfEZEz27QWuzQCo8dnyMmRFAP7dx0t338Z3nt9nocLIXo/Bq+pFu7/ X6GNdkdh3jOOefOvpbvL32DQvzZiCsXxlCnC2tJNh6gfUeSUhHdun8kylKWgwBqC RJeGGjxVQpEbqbMZxLsgKfwVypoXfUEOWqh16uLa99PWGP9kGEq1rKFuynSzAMNU MpmaO6wjM5YrEsO9yKgPLMaWo7ZAFSWNIBeBAwMjUrzpN9jdsZ5WoDTroA9p/Bwq yT37bSgArHSec/02BgVIjvnhHCC7zNrU3hJObp+5JOAwH0R68Dh/r4I444ygboBI eyx8Zy+W55Gsh8agHSUM7dCb6jqj0c4/ni/Fttc7y2j94LJ6wUZ8gOiBx7+iCXEG 4NlGrjIjcj//ty9sRB0+yjZPDdJzK7IjJybg7fjDoYC+XcQUfXB5ux9LbZP1oKkx CkTAwrJhmXmtB3OM+fny/R3J+L2eq1Whlre1SulKEE8AiDXy7pdCf+IFB+tnZIuT LdkJgnsinELlGV368K7Xk3cD3RuOpAydv3Zd5nxBrGGrGNR6cxRgJoUB8qVNPuyR 0CGIIaj5+4AxqUeEYDLO =VmOK -----END PGP SIGNATURE----- --nextPart2890720.IdmipqFpt4-- From nobody Sun Dec 6 08:17:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7551AD0B0 for ; Sun, 6 Dec 2015 08:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, T_RP_MATCHES_RCVD=-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 dbfdTX46_10N for ; Sun, 6 Dec 2015 08:17:05 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16F71AD0AF for ; Sun, 6 Dec 2015 08:17:05 -0800 (PST) Received: by iouu10 with SMTP id u10so163167971iou.0 for ; Sun, 06 Dec 2015 08:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EbOGgVTrD8piQ7StYZagiSUhkuCaHgPkrn3EhpH17q8=; b=bFvSWua8RSXcY9eVUbQ/8KKSnuEy0EMjzWbJhNW6t50E7aZBmLqV9MwPbb4gzYd10l 3etnu5Ulp6ByPnc299TZtZyIs+ROav+Ia9CZr8mnV1C1Hta5f5ZSCIZKefuIeloTPl6G ZpPwR8QTQNonPj9Caexgg+wCbdLli/7kE+TREecl7wfwXcUxf9f8WgHjWZtzHK5BSrqf q0MRjp0rLsm6w1SdVaEuLgAgZLMNwM2uWdO4i8M50NdshpqWNd4Td6E36wzGTLBaJwog 0Glt+ewrrhudBNA8WqRDZxmIHD+U6AUrl2C9XLI6Vci68G7v7wSMf36//jedYvIlmU3a fOkg== 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=EbOGgVTrD8piQ7StYZagiSUhkuCaHgPkrn3EhpH17q8=; b=k9NH8QTOebm+yg6qJGXR/xgIp+Qc1LTWAiZwv0LBGUKZ0RvopT9Zs80C+o5kUFe7d1 7uIgf7uBLvXwRpq4sdahSYvDSdfiV0hveUfrP/MjuKSdkeXrCh/pB4N+DCg+WphT4jt+ DFNIlkQRxuttGB0pjs4fHD2lbCm9BLhkvjWxqN8MVCtFUAiPDXVz45mEcGwAWCYXLqFU c1F5AZQrBmt4Dnqq0WvI9YuSpNhfMBtIzGDt4Aj5uGs1gWSppXdKiTA5as3MjhWYcbJz y9q04KBgMQrVyfU1So26NrHdqWROh94yEe7Jj+WnTPKaLyn10Hp+s8VARWxI6xf+9YZC gtvg== X-Gm-Message-State: ALoCoQln8uSTLx4DKIW+y9n3I69OfodIJ+GZa2CW/26+O8rzdZF3W54hAuGkNdmxSItIQYOI/rsg MIME-Version: 1.0 X-Received: by 10.107.152.133 with SMTP id a127mr23217725ioe.60.1449418624954; Sun, 06 Dec 2015 08:17:04 -0800 (PST) Received: by 10.107.173.15 with HTTP; Sun, 6 Dec 2015 08:17:04 -0800 (PST) In-Reply-To: References: Date: Sun, 6 Dec 2015 08:17:04 -0800 Message-ID: From: Bill Cox To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1140e69e45b99d05263d12ce Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Forward secrecy with resumption, and 0-RTT security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 16:17:09 -0000 --001a1140e69e45b99d05263d12ce Content-Type: text/plain; charset=UTF-8 On Sun, Dec 6, 2015 at 7:12 AM, Eric Rescorla wrote: > On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox wrote: > >> AFAIK, there has never been a session resumed with forward secrecy. Is >> this correct? >> > > Yes, session resumption does not have PFS. Though note that with 1.3 that > will > no longer be true, because you can do PSK-DHE. > With PSK-DHE over 0-RTT, would we use the static DHE server share for the first resume flight? In that case, we still lose first flight strict forward secrecy, though with 1-RTT it seems to work perfectly. I just have doubts that 1-RTT is going to be used much. > > >> In the past, there were two cases: resumption using session IDs, and >> resumption with session tickets. Using session IDs loses forward secrecy, >> because the server always has session keys in a session cache, which could >> be used to decrypt the prior sessions. Using tickets did not work either, >> because the server always kept a ticket decryption key which could be used >> to decrypt all resumed sessions since the key was last rotated. >> > > Well, the server could in principle delete the keys from the session cache > and (at more > cost) the decryption key But yes. > > It could also just rekey the keys by hashing them, or something like that. With server-side state, forward secrecy seems straight forward to achieve. > To have strict forward secrecy, given that the server already has to have >> server-side state (the pre-shared key), I find the old session ID scheme >> more palatable than the new tickets. The main point of session tickets was >> to eliminate the server-side session cache, wasn't it? >> > > The current ticket scheme is compatible with either a server-side database > *or* having self-contained > tickets which are encrypted with a server-side key. (This was also true > for tickets, it's just that > you didn't bother with tickets if that is what you wanted). If you want a > database, you just use > an identifier as the key name. The point is to have a mechanism which > accomodates either > design. > I think this is a very cool aspect of TLS 1.3. Inefficiencies always bug me, though. It is somewhat painful transmitting 0's in the SessionID field, when we could use that to lookup saved server-side state, reducing or eliminating the ticket while still supporting 0-RTT resume. However, I lean pretty far on the side of efficiency. Microseconds and bytes matter, IMO. > I think the current spec does not describe well enough how to implement >> secure 0-RTT infrastructure. Instead, it seems to recommend against using >> 0-RTT, with a pretty dire warning about the insecurity of 0-RTT. >> > > Well, the primary purpose of this warning isn't to warn about PFS. It's > really to warn > about the replay issue, which is unique to 0-RTT and which can't really be > fixed > by proper implementation. The issue isn't that it's not possible to have > anti-replay > if you're willing to store server side state, but rather how you respond > to server-side state > loss. Moreover, the problems exist whether or not you use certificate-based > client authentication. > Agreed. The anti-replay warning should remain. We can mitigate, but not eliminate this issue. > I haven't thought this through in as much detail as I've thought through > the > non-PSK 0-RTT case, but I don't believe that PSK-resumption solves the > problems with replay. The basic issue is the same: what happens when > a server gets a connection attached to state which it doesn't have. So, > what the attacker would do duplicate the ClientHello + PSK and send one > copy to the true datacenter and one to another datacenter that doesn't have > state. The right datacenter will process the 0-RTT handshake and the > wrong one will reject it, causing the client to fall back to 1-RTT and > retransmit > the request. So, you still get replay. > > -Ekr > Correct. PSK does not solve this replay issue. It only defends against replay to the same data center. This increases the complexity of the attack and limits the number of times a packet can be replayed, but does not solve the replay issue. Further mitigation steps, such as making all requests idempotent (regardless of 0-RTT or 1-RTT), should be taken above the TLS layer, at the application layer. Datacenter bound PSK 0-RTT does solve the uniqueness problem with ClientVerify signatures. There would be at most one accepted flight of packets per signing operation, even in your attack scenario. IMO, ClientVerify should only be supported if this weaker form of replay protection is in place. Here's a threat model: A woman enters a hotel lobby, desperate for access to an online computer. She uses a computer in the "business center" to access her online account, which requires her to insert her security key containing her client certificate. When she's done with her work, she logs out, removes the security key, and just to be safe smashes the computer into useless bits. The attacker who previously installed malware on the computer now is able to make a large number of new authenticated connections over several days, with many connections in parallel, even though he no longer has access to the security key to act as a signing oracle. This is what you get using ClientVerify without taking steps to verify both uniqueness and freshness of signatures. If you only insure freshness, you get a bunch of parallel authenticated connections that are long-lasting. If you only insure uniqueness, you get malware using the security key rapid-fire as a signing oracle to authorize many new connections in the future. You have to have both uniqueness and freshness in a useful proof-of-possession. We can insure uniqueness, and if the security key in this case had an accurate clock, we could also insure freshness. Another thing: resumption in TLS 1.2 breaks this security key scenario as well. Malware simply exports the session state and resumption ticket, and the attacker then resumes authenticated connections without access to the security key. To fix this, there needs to be a new PoP per connection, not just once on the initial handshake. I guess another question is: Do we care about strong client authentication enough to support it in a 0-RTT world? The default solution when using TLS 1.3 is for companies that use security keys to never use 0-RTT authentication. That's not the end of the world, but I imagine that having to support 0-RTT for regular users, and forcing 1-RTT for employees and users who choose a higher level of security is going to be a complication. I still think some more text describing 0-RTT implementation techniques would be a good thing. It really does read as if the spec is saying that servers SHOULD NOT support 0-RTT. I've never read a security warning like that which did not have a SHOULD NOT associated with it. Of course, I haven't read that many IETF specs yet :) Bill On Sun, Dec 6, 2015 at 7:12 AM, Eric Rescorla wrote: > On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox wrote: > >> AFAIK, there has never been a session resumed with forward secrecy. Is >> this correct? >> > > Yes, session resumption does not have PFS. Though note that with 1.3 that > will > no longer be true, because you can do PSK-DHE. > > > > >> In the past, there were two cases: resumption using session IDs, and >> resumption with session tickets. Using session IDs loses forward secrecy, >> because the server always has session keys in a session cache, which could >> be used to decrypt the prior sessions. Using tickets did not work either, >> because the server always kept a ticket decryption key which could be used >> to decrypt all resumed sessions since the key was last rotated. >> > > Well, the server could in principle delete the keys from the session cache > and (at more > cost) the decryption key But yes. > > > > >> To have forward secrecy under the strict definition using the new PSK >> scheme, we need to use what the new name implies: pre _shared_ keys. The >> new name implies that the server remembers a unique shared key for the >> connection, which is server-side state per resumable connection. If we >> only store the PSK in the ticket, and go stateless on the server, then the >> server-side ticket decryption key again defeats strict forward secrecy. >> With a remembered server-side pre-shared secret, we can have a 0-RTT resume >> with strict forward secrecy. Is this already implied in the spec? If so, >> the spec could be improved, by stating this explicitly. However, the >> current statement that 0-RTT does not provide forward secrecy seems to be >> wrong in the case that we resume a 0-RTT connections with a >> server-remembered PSK. >> >> To have strict forward secrecy, given that the server already has to have >> server-side state (the pre-shared key), I find the old session ID scheme >> more palatable than the new tickets. The main point of session tickets was >> to eliminate the server-side session cache, wasn't it? >> > > The current ticket scheme is compatible with either a server-side database > *or* having self-contained > tickets which are encrypted with a server-side key. (This was also true > for tickets, it's just that > you didn't bother with tickets if that is what you wanted). If you want a > database, you just use > an identifier as the key name. The point is to have a mechanism which > accomodates either > design. > > > I think the current spec does not describe well enough how to implement >> secure 0-RTT infrastructure. Instead, it seems to recommend against using >> 0-RTT, with a pretty dire warning about the insecurity of 0-RTT. >> > > Well, the primary purpose of this warning isn't to warn about PFS. It's > really to warn > about the replay issue, which is unique to 0-RTT and which can't really be > fixed > by proper implementation. The issue isn't that it's not possible to have > anti-replay > if you're willing to store server side state, but rather how you respond > to server-side state > loss. Moreover, the problems exist whether or not you use certificate-based > client authentication. > > I haven't thought this through in as much detail as I've thought through > the > non-PSK 0-RTT case, but I don't believe that PSK-resumption solves the > problems with replay. The basic issue is the same: what happens when > a server gets a connection attached to state which it doesn't have. So, > what the attacker would do duplicate the ClientHello + PSK and send one > copy to the true datacenter and one to another datacenter that doesn't have > state. The right datacenter will process the 0-RTT handshake and the > wrong one will reject it, causing the client to fall back to 1-RTT and > retransmit > the request. So, you still get replay. > > -Ekr > > > --001a1140e69e45b99d05263d12ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Dec 6, 2015 at 7:12 AM, Eric Rescorla <ekr@rtfm.com> wrote:
On Sun, Dec 6, 2015 at 6:50 A= M, Bill Cox <waywardgeek@google.com> wrote:

AFAIK, there has ne= ver been a session resumed with forward secrecy.=C2=A0 Is this correct?


Yes, session re= sumption does not have PFS. Though note that with 1.3 that will
n= o longer be true, because you can do PSK-DHE.

With PSK-DHE = over 0-RTT, would we use the static DHE server share for the first resume f= light?=C2=A0 In that case, we still lose first flight strict forward secrec= y, though with 1-RTT it seems to work perfectly.=C2=A0 I just have doubts t= hat 1-RTT is going to be used much.
=C2=A0

In the past, there were tw= o cases: resumption using session IDs, and resumption with session tickets.= =C2=A0 Using session IDs loses forward secrecy, because the server always h= as session keys in a session cache, which could be used to decrypt the prio= r sessions.=C2=A0 Using tickets did not work either, because the server alw= ays kept a ticket decryption key which could be used to decrypt all resumed= sessions since the key was last rotated.


Well, the server could in principle delete th= e keys from the session cache and (at more
cost) the decryption k= ey But yes.

<= /blockquote>

It could also just rekey the keys by hashin= g them, or something like that.=C2=A0 With server-side state, forward secre= cy seems straight forward to achieve.=C2=A0

To have strict forward secre= cy, given that the server already has to have server-side state (the pre-sh= ared key), I find the old session ID scheme more palatable than the new tic= kets.=C2=A0 The main point of session tickets was to eliminate the server-s= ide session cache, wasn't it?

=
The current ticket scheme is compatible with either a= server-side database *or* having self-contained
tickets which ar= e encrypted with a server-side key. (This was also true for tickets, it'= ;s just that
you didn't bother with tickets if that is what y= ou wanted). If you want a database, you just use
an identifier as= the key name. The point is to have a mechanism which accomodates either
design.

I t= hink this is a very cool aspect of TLS 1.3.=C2=A0 Inefficiencies always bug= me, though.=C2=A0 It is somewhat painful transmitting 0's in the Sessi= onID field, when we could use that to lookup saved server-side state, reduc= ing or eliminating the ticket while still supporting 0-RTT resume.=C2=A0 Ho= wever, I lean pretty far on the side of efficiency.=C2=A0 Microseconds and = bytes matter, IMO.
=C2=A0

I think the current spec does not describe well= enough how to implement secure 0-RTT infrastructure.=C2=A0 Instead, it see= ms to recommend against using 0-RTT, with a pretty dire warning about the i= nsecurity of 0-RTT.


Well, the primary purpose of this warning isn't to warn about P= FS. It's really to warn
about the replay issue, which is uniq= ue to 0-RTT and which can't really be fixed
by proper impleme= ntation. The issue isn't that it's not possible to have anti-replay=
if you're willing to store server side state, but rather how= you respond to server-side state
loss. Moreover, the problems ex= ist whether or not you use certificate-based
client authenticatio= n.

Agreed.=C2=A0 Th= e anti-replay warning should remain.=C2=A0 We can mitigate, but not elimina= te this issue.
=C2=A0
I have= n't thought this through in as much detail as I've thought through = the
non-PSK 0-RTT case, but I don't believe that PSK-resumpti= on solves the
problems with replay. The basic issue is the same: = what happens when
a server gets a connection attached to state wh= ich it doesn't have. So,
what the attacker would do duplicate= the ClientHello + PSK and send one
copy to the true datacenter a= nd one to another datacenter that doesn't have
state. The rig= ht datacenter will process the 0-RTT handshake and the
wrong one = will reject it, causing the client to fall back to 1-RTT and retransmit
the request. So, you still get replay.

-Ekr=

Correct.=C2=A0 PSK= does not solve this replay issue.=C2=A0 It only defends against replay to = the same data center. This increases the complexity of the attack and limit= s the number of times a packet can be replayed, but does not solve the repl= ay issue.=C2=A0 Further mitigation steps, such as making all requests idemp= otent (regardless of 0-RTT or 1-RTT), should be taken above the TLS layer, = at the application layer.=C2=A0 Datacenter bound PSK 0-RTT does solve the u= niqueness problem with ClientVerify signatures.=C2=A0 There would be at mos= t one accepted flight of packets per signing operation, even in your attack= scenario.

IMO, ClientVerify should only be suppor= ted if this weaker form of replay protection is in place.=C2=A0 Here's = a threat model:

A woman enters a hotel lobby, desp= erate for access to an online computer.=C2=A0 She uses a computer in the &q= uot;business center" to access her online account, which requires her = to insert her security key containing her client certificate.=C2=A0 When sh= e's done with her work, she logs out, removes the security key, and jus= t to be safe smashes the computer into useless bits.

The attacker who previously installed malware on the computer now is abl= e to make a large number of new authenticated connections over several days= , with many connections in parallel, even though he no longer has access to= the security key to act as a signing oracle.

This= is what you get using ClientVerify without taking steps to verify both uni= queness and freshness of signatures.=C2=A0 If you only insure freshness, yo= u get a bunch of parallel authenticated connections that are long-lasting.= =C2=A0 If you only insure uniqueness, you get malware using the security ke= y rapid-fire as a signing oracle to authorize many new connections in the f= uture.=C2=A0 You have to have both uniqueness and freshness in a useful pro= of-of-possession.=C2=A0 We can insure uniqueness, and if the security key i= n this case had an accurate clock, we could also insure freshness.

Another thing: resumption in TLS 1.2 breaks this security = key scenario as well.=C2=A0 Malware simply exports the session state and re= sumption ticket, and the attacker then resumes authenticated connections wi= thout access to the security key.=C2=A0 To fix this, there needs to be a ne= w PoP per connection, not just once on the initial handshake.
I guess another question is: Do we care about strong client aut= hentication enough to support it in a 0-RTT world?=C2=A0 The default soluti= on when using TLS 1.3 is for companies that use security keys to never use = 0-RTT authentication.=C2=A0 That's not the end of the world, but I imag= ine that having to support 0-RTT for regular users, and forcing 1-RTT for e= mployees and users who choose a higher level of security is going to be a c= omplication.

I still think some more text describi= ng 0-RTT implementation techniques would be a good thing.=C2=A0 It really d= oes read as if the spec is saying that servers SHOULD NOT support 0-RTT.=C2= =A0 I've never read a security warning like that which did not have a S= HOULD NOT associated with it.=C2=A0 Of course, I haven't read that many= IETF specs yet :)

Bill

On Sun, Dec 6, 2015 = at 7:12 AM, Eric Rescorla <ekr@rtfm.com> wrote:
On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox <waywardgeek@google.com> wrote:

AFAIK, there has never been a sessi= on resumed with forward secrecy.=C2=A0 Is this correct?


Yes, session resumption does no= t have PFS. Though note that with 1.3 that will
no longer be true= , because you can do PSK-DHE.

=C2=A0

In the past, there were two cases= : resumption using session IDs, and resumption with session tickets.=C2=A0 = Using session IDs loses forward secrecy, because the server always has sess= ion keys in a session cache, which could be used to decrypt the prior sessi= ons.=C2=A0 Using tickets did not work either, because the server always kep= t a ticket decryption key which could be used to decrypt all resumed sessio= ns since the key was last rotated.


Well, the server could in principle delete the keys = from the session cache and (at more
cost) the decryption key But = yes.


=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">

To have forward secrecy under the strict definition using = the new PSK scheme, we need to use what the new name implies: pre _shared_ = keys.=C2=A0 The new name implies that the server remembers a unique shared = key for the connection, which is server-side state per resumable connection= .=C2=A0 If we only store the PSK in the ticket, and go stateless on the ser= ver, then the server-side ticket decryption key again defeats strict forwar= d secrecy.=C2=A0 With a remembered server-side pre-shared secret, we can ha= ve a 0-RTT resume with strict forward secrecy.=C2=A0 Is this already implie= d in the spec?=C2=A0 If so, the spec could be improved, by stating this exp= licitly.=C2=A0 However, the current statement that 0-RTT does not provide f= orward secrecy seems to be wrong in the case that we resume a 0-RTT connect= ions with a server-remembered PSK.


To have strict forward secrecy, given that the s= erver already has to have server-side state (the pre-shared key), I find th= e old session ID scheme more palatable than the new tickets.=C2=A0 The main= point of session tickets was to eliminate the server-side session cache, w= asn't it?


The current ticket scheme is compatible with either a server-side databas= e *or* having self-contained
tickets which are encrypted with a s= erver-side key. (This was also true for tickets, it's just that
you didn't bother with tickets if that is what you wanted). If you w= ant a database, you just use
an identifier as the key name. The p= oint is to have a mechanism which accomodates either
design.


I think= the current spec does not describe well enough how to implement secure 0-R= TT infrastructure.=C2=A0 Instead, it seems to recommend against using 0-RTT= , with a pretty dire warning about the insecurity of 0-RTT.


Well, the primary purpose o= f this warning isn't to warn about PFS. It's really to warn
about the replay issue, which is unique to 0-RTT and which can't rea= lly be fixed
by proper implementation. The issue isn't that i= t's not possible to have anti-replay
if you're willing to= store server side state, but rather how you respond to server-side state
loss. Moreover, the problems exist whether or not you use certific= ate-based
client authentication.

I haven= 't thought this through in as much detail as I've thought through t= he
non-PSK 0-RTT case, but I don't believe that PSK-resumptio= n solves the
problems with replay. The basic issue is the same: w= hat happens when
a server gets a connection attached to state whi= ch it doesn't have. So,
what the attacker would do duplicate = the ClientHello + PSK and send one
copy to the true datacenter an= d one to another datacenter that doesn't have
state. The righ= t datacenter will process the 0-RTT handshake and the
wrong one w= ill reject it, causing the client to fall back to 1-RTT and retransmit
the request. So, you still get replay.

-Ekr<= /div>



--001a1140e69e45b99d05263d12ce-- From nobody Sun Dec 6 11:39:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570E11A88BA for ; Sun, 6 Dec 2015 11:39:58 -0800 (PST) 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, HTML_MESSAGE=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 buW8_MyzyrWQ for ; Sun, 6 Dec 2015 11:39:55 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D6D1A88AD for ; Sun, 6 Dec 2015 11:39:54 -0800 (PST) Received: by ykba77 with SMTP id a77so173833510ykb.2 for ; Sun, 06 Dec 2015 11:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8R8UxwUjH4QyEW9syGuqrisd2RNpq1TKBsj5zEGqg0M=; b=ZkObdoNI5YF8SgXlUDQaVGM/+U65kEXoo3X9O6WeCgH/hbc5RcFPvAYa9Bhh6XSmef zcnuqvC/eCKKxh0r3MNMMDawtlEYIt4nGKOjQ27b57ZaciZxgk/sMWLqCz797PsKa76g LD7LWv6kiM9gxhfXeLe2zyk/hcXcbZq/nhVS+pnf68J5VZ75M1JLW+R9XvZfi9ELcb92 q5YWgJ7pu88ErhQcVO0nLwZqfAyNWpiLNm//oWTc3lj5wVa41TmYwpoSQaufApLv+3DI WARPNSNdO6gOzA1UEbO9gCskKwdwVCQIuRQujZ2MnZjig5Oa3LF5lsjCSq4oN4z/Lkrd 3B6w== 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=8R8UxwUjH4QyEW9syGuqrisd2RNpq1TKBsj5zEGqg0M=; b=NfV30+NgBLSgK5tc7mBVuuvpUmJiIN41DTOPwdZGna4KHtcW8GWV4pla5iFFAG4Sxc c5sgPY/VSTd4BJEuouqV5jdzpxCCD9BcUJCPQE2OuHResjEGZeeSMaNjdGP7HQyJoJLz lbStquFv+xslYZFTWxmNhNrn1Q9LAVsfRNt0IXIkPZ2Ru6yML0Frp80dUc7rGiV6hjmy R7UO6KnFSrJk7ApCXslv3S8HI17+qF0PxTznwid1ZAmp4XOunxs677rgaTG08ypWARyw UagHpNjyYsu4o8a4PnqnLcu7+3fPi3y3wdd5voaoFiX+DJmVrrxhEYi3HGPFJVQvq+of 28GQ== X-Gm-Message-State: ALoCoQl0E4n0Fg5irIrqmzwZIbZ0pEHmlXQAF+g7i0dGIfDV9bXc6y91e1PyphGEoiF7aMmbB2Z7 X-Received: by 10.13.236.10 with SMTP id v10mr22609889ywe.231.1449430794081; Sun, 06 Dec 2015 11:39:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Sun, 6 Dec 2015 11:39:14 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sun, 6 Dec 2015 11:39:14 -0800 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=94eb2c0889dc9bcd2905263fe75b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Forward secrecy with resumption, and 0-RTT security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 19:39:58 -0000 --94eb2c0889dc9bcd2905263fe75b Content-Type: text/plain; charset=UTF-8 On Sun, Dec 6, 2015 at 8:17 AM, Bill Cox wrote: > On Sun, Dec 6, 2015 at 7:12 AM, Eric Rescorla wrote: > >> On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox wrote: >> >>> AFAIK, there has never been a session resumed with forward secrecy. Is >>> this correct? >>> >> >> Yes, session resumption does not have PFS. Though note that with 1.3 that >> will >> no longer be true, because you can do PSK-DHE. >> > > With PSK-DHE over 0-RTT, would we use the static DHE server share for the > first resume flight? > No. In All PSK-DHE modes, the PSK is used as SS. > To have strict forward secrecy, given that the server already has to have >>> server-side state (the pre-shared key), I find the old session ID scheme >>> more palatable than the new tickets. The main point of session tickets was >>> to eliminate the server-side session cache, wasn't it? >>> >> >> The current ticket scheme is compatible with either a server-side >> database *or* having self-contained >> tickets which are encrypted with a server-side key. (This was also true >> for tickets, it's just that >> you didn't bother with tickets if that is what you wanted). If you want a >> database, you just use >> an identifier as the key name. The point is to have a mechanism which >> accomodates either >> design. >> > > I think this is a very cool aspect of TLS 1.3. Inefficiencies always bug > me, though. It is somewhat painful transmitting 0's in the SessionID > field, when we could use that to lookup saved server-side state, reducing > or eliminating the ticket while still supporting 0-RTT resume. However, I > lean pretty far on the side of efficiency. Microseconds and bytes matter, > IMO. > You're talking about the single byte that indicates an empty session id? That doesn't seem like it's a big source of inefficiency. > I haven't thought this through in as much detail as I've thought through >> the >> non-PSK 0-RTT case, but I don't believe that PSK-resumption solves the >> problems with replay. The basic issue is the same: what happens when >> a server gets a connection attached to state which it doesn't have. So, >> what the attacker would do duplicate the ClientHello + PSK and send one >> copy to the true datacenter and one to another datacenter that doesn't >> have >> state. The right datacenter will process the 0-RTT handshake and the >> wrong one will reject it, causing the client to fall back to 1-RTT and >> retransmit >> the request. So, you still get replay. >> >> -Ekr >> > > Correct. PSK does not solve this replay issue. It only defends against > replay to the same data center. This increases the complexity of the attack > and limits the number of times a packet can be replayed, but does not solve > the replay issue. Further mitigation steps, such as making all requests > idempotent (regardless of 0-RTT or 1-RTT), should be taken above the TLS > layer, at the application layer. Datacenter bound PSK 0-RTT does solve the > uniqueness problem with ClientVerify signatures. There would be at most > one accepted flight of packets per signing operation, even in your attack > scenario. > > IMO, ClientVerify should only be supported if this weaker form of replay > protection is in place. Here's a threat model: > > A woman enters a hotel lobby, desperate for access to an online computer. > She uses a computer in the "business center" to access her online account, > which requires her to insert her security key containing her client > certificate. When she's done with her work, she logs out, removes the > security key, and just to be safe smashes the computer into useless bits. > > The attacker who previously installed malware on the computer now is able > to make a large number of new authenticated connections over several days, > with many connections in parallel, even though he no longer has access to > the security key to act as a signing oracle. > Yes, assuming the malware captures the client's DHE share. I've updated the draft to make this point clear. To be clear, the original issue with replay would still apply here as well, since the client would just sign twice. Another thing: resumption in TLS 1.2 breaks this security key scenario as > well. Malware simply exports the session state and resumption ticket, and > the attacker then resumes authenticated connections without access to the > security key. To fix this, there needs to be a new PoP per connection, not > just once on the initial handshake. > Yes, that's one reason that people require fresh signatures on subsequent connections in systems like FIDO, even though they have a token that demonstrates continuity of the client (though typically that token is a cokie). I guess another question is: Do we care about strong client authentication > enough to support it in a 0-RTT world? The default solution when using TLS > 1.3 is for companies that use security keys to never use 0-RTT > authentication. That's not the end of the world, but I imagine that having > to support 0-RTT for regular users, and forcing 1-RTT for employees and > users who choose a higher level of security is going to be a complication. > Yes, I think it's important, especially for WebRTC. > > I still think some more text describing 0-RTT implementation techniques > would be a good thing. It really does read as if the spec is saying that > servers SHOULD NOT support 0-RTT. I've never read a security warning like > that which did not have a SHOULD NOT associated with it. Of course, I > haven't read that many IETF specs yet :) > I'll but it on my TODO list but I would definitely welcome a PR here. Thanks, -Ekr > Bill > > On Sun, Dec 6, 2015 at 7:12 AM, Eric Rescorla wrote: > >> On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox wrote: >> >>> AFAIK, there has never been a session resumed with forward secrecy. Is >>> this correct? >>> >> >> Yes, session resumption does not have PFS. Though note that with 1.3 that >> will >> no longer be true, because you can do PSK-DHE. >> >> >> >> >>> In the past, there were two cases: resumption using session IDs, and >>> resumption with session tickets. Using session IDs loses forward secrecy, >>> because the server always has session keys in a session cache, which could >>> be used to decrypt the prior sessions. Using tickets did not work either, >>> because the server always kept a ticket decryption key which could be used >>> to decrypt all resumed sessions since the key was last rotated. >>> >> >> Well, the server could in principle delete the keys from the session >> cache and (at more >> cost) the decryption key But yes. >> >> >> >> >>> To have forward secrecy under the strict definition using the new PSK >>> scheme, we need to use what the new name implies: pre _shared_ keys. The >>> new name implies that the server remembers a unique shared key for the >>> connection, which is server-side state per resumable connection. If we >>> only store the PSK in the ticket, and go stateless on the server, then the >>> server-side ticket decryption key again defeats strict forward secrecy. >>> With a remembered server-side pre-shared secret, we can have a 0-RTT resume >>> with strict forward secrecy. Is this already implied in the spec? If so, >>> the spec could be improved, by stating this explicitly. However, the >>> current statement that 0-RTT does not provide forward secrecy seems to be >>> wrong in the case that we resume a 0-RTT connections with a >>> server-remembered PSK. >>> >>> To have strict forward secrecy, given that the server already has to >>> have server-side state (the pre-shared key), I find the old session ID >>> scheme more palatable than the new tickets. The main point of session >>> tickets was to eliminate the server-side session cache, wasn't it? >>> >> >> The current ticket scheme is compatible with either a server-side >> database *or* having self-contained >> tickets which are encrypted with a server-side key. (This was also true >> for tickets, it's just that >> you didn't bother with tickets if that is what you wanted). If you want a >> database, you just use >> an identifier as the key name. The point is to have a mechanism which >> accomodates either >> design. >> >> >> I think the current spec does not describe well enough how to implement >>> secure 0-RTT infrastructure. Instead, it seems to recommend against using >>> 0-RTT, with a pretty dire warning about the insecurity of 0-RTT. >>> >> >> Well, the primary purpose of this warning isn't to warn about PFS. It's >> really to warn >> about the replay issue, which is unique to 0-RTT and which can't really >> be fixed >> by proper implementation. The issue isn't that it's not possible to have >> anti-replay >> if you're willing to store server side state, but rather how you respond >> to server-side state >> loss. Moreover, the problems exist whether or not you use >> certificate-based >> client authentication. >> >> I haven't thought this through in as much detail as I've thought through >> the >> non-PSK 0-RTT case, but I don't believe that PSK-resumption solves the >> problems with replay. The basic issue is the same: what happens when >> a server gets a connection attached to state which it doesn't have. So, >> what the attacker would do duplicate the ClientHello + PSK and send one >> copy to the true datacenter and one to another datacenter that doesn't >> have >> state. The right datacenter will process the 0-RTT handshake and the >> wrong one will reject it, causing the client to fall back to 1-RTT and >> retransmit >> the request. So, you still get replay. >> >> -Ekr >> >> >> > --94eb2c0889dc9bcd2905263fe75b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Dec 6, 2015 at 8:17 AM, Bill Cox <waywardgeek@google.com= > wrote:
<= div class=3D"gmail_extra">
On Su= n, Dec 6, 2015 at 7:12 AM, Eric Rescorla <ekr@rtfm.com> wrote:
On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox = <waywardgeek@google.com> wrote:

AFAIK, there has never been a s= ession resumed with forward secrecy.=C2=A0 Is this correct?


Yes, session resumption doe= s not have PFS. Though note that with 1.3 that will
no longer be = true, because you can do PSK-DHE.
=

With PSK-DHE over 0-RTT, woul= d we use the static DHE server share for the first resume flight?=C2=A0

No. In All PSK-DHE mod= es, the PSK is used as SS.

<= br>

To have= strict forward secrecy, given that the server already has to have server-s= ide state (the pre-shared key), I find the old session ID scheme more palat= able than the new tickets.=C2=A0 The main point of session tickets was to e= liminate the server-side session cache, wasn't it?


The current ticket scheme is com= patible with either a server-side database *or* having self-contained
=
tickets which are encrypted with a server-side key. (This was also tru= e for tickets, it's just that
you didn't bother with tick= ets if that is what you wanted). If you want a database, you just use
=
an identifier as the key name. The point is to have a mechanism which = accomodates either
design.

I think this is a very cool aspect of TLS 1.3.=C2= =A0 Inefficiencies always bug me, though.=C2=A0 It is somewhat painful tran= smitting 0's in the SessionID field, when we could use that to lookup s= aved server-side state, reducing or eliminating the ticket while still supp= orting 0-RTT resume.=C2=A0 However, I lean pretty far on the side of effici= ency.=C2=A0 Microseconds and bytes matter, IMO.

You're talking about the single byte that = indicates an empty session id? That doesn't seem like
it'= s a big source of inefficiency.

=C2=A0
I haven't thought this through in as much detail as I've thou= ght through the
non-PSK 0-RTT case, but I don't believe that = PSK-resumption solves the
problems with replay. The basic issue i= s the same: what happens when
a server gets a connection attached= to state which it doesn't have. So,
what the attacker would = do duplicate the ClientHello + PSK and send one
copy to the true = datacenter and one to another datacenter that doesn't have
st= ate. The right datacenter will process the 0-RTT handshake and the
wrong one will reject it, causing the client to fall back to 1-RTT and re= transmit
the request. So, you still get replay.

-Ekr

Correct.=C2=A0 PSK does not solve this replay issue.=C2=A0 It only defends= against replay to the same data center. This increases the complexity of t= he attack and limits the number of times a packet can be replayed, but does= not solve the replay issue.=C2=A0 Further mitigation steps, such as making= all requests idempotent (regardless of 0-RTT or 1-RTT), should be taken ab= ove the TLS layer, at the application layer.=C2=A0 Datacenter bound PSK 0-R= TT does solve the uniqueness problem with ClientVerify signatures.=C2=A0 Th= ere would be at most one accepted flight of packets per signing operation, = even in your attack scenario.

IMO, ClientVerify sh= ould only be supported if this weaker form of replay protection is in place= .=C2=A0 Here's a threat model:

A woman enters = a hotel lobby, desperate for access to an online computer.=C2=A0 She uses a= computer in the "business center" to access her online account, = which requires her to insert her security key containing her client certifi= cate.=C2=A0 When she's done with her work, she logs out, removes the se= curity key, and just to be safe smashes the computer into useless bits.

The attacker who previously installed malware on the = computer now is able to make a large number of new authenticated connection= s over several days, with many connections in parallel, even though he no l= onger has access to the security key to act as a signing oracle.

Yes, assuming the malware cap= tures the client's DHE share.=C2=A0 I've updated the draft to make = this
point clear.

To be clear, the origi= nal issue with replay would still apply here as well, since the client
would just sign twice.


Another thing: resumption in TLS 1.2 breaks this secu= rity key scenario as well.=C2=A0 Malware simply exports the session state a= nd resumption ticket, and the attacker then resumes authenticated connectio= ns without access to the security key.=C2=A0 To fix this, there needs to be= a new PoP per connection, not just once on the initial handshake.

Yes, that's one reason = that people require fresh signatures on subsequent connections
in= systems like FIDO, even though they have a token that demonstrates continu= ity of
the client (though typically that token is a cokie).
=


I guess anoth= er question is: Do we care about strong client authentication enough to sup= port it in a 0-RTT world?=C2=A0 The default solution when using TLS 1.3 is = for companies that use security keys to never use 0-RTT authentication.=C2= =A0 That's not the end of the world, but I imagine that having to suppo= rt 0-RTT for regular users, and forcing 1-RTT for employees and users who c= hoose a higher level of security is going to be a complication.
=

Yes, I think it's importan= t, especially for WebRTC.
=C2=A0
=

I still think some more text describing 0-RTT implement= ation techniques would be a good thing.=C2=A0 It really does read as if the= spec is saying that servers SHOULD NOT support 0-RTT.=C2=A0 I've never= read a security warning like that which did not have a SHOULD NOT associat= ed with it.=C2=A0 Of course, I haven't read that many IETF specs yet :)=

I'll but it on= my TODO list but I would definitely welcome a PR here.

Thanks,
-Ekr


=C2=A0=
Bill
<= div class=3D"h5">

= On Sun, Dec 6, 2015 at 7:12 AM, Eric Rescorla <ekr@rtfm.com> wrot= e:
On Sun, Dec 6, 2015 at 6:50 AM, Bill= Cox <waywardgeek@google.com> wrote:

AFAIK, there has never bee= n a session resumed with forward secrecy.=C2=A0 Is this correct?

=

Yes, session resumptio= n does not have PFS. Though note that with 1.3 that will
no longe= r be true, because you can do PSK-DHE.


<= /div>
=C2=A0

In the past, there were two cases= : resumption using session IDs, and resumption with session tickets.=C2=A0 = Using session IDs loses forward secrecy, because the server always has sess= ion keys in a session cache, which could be used to decrypt the prior sessi= ons.=C2=A0 Using tickets did not work either, because the server always kep= t a ticket decryption key which could be used to decrypt all resumed sessio= ns since the key was last rotated.


Well, the server could in principle delete the keys = from the session cache and (at more
cost) the decryption key But = yes.


=C2=A0

To have forward secrecy under the strict definition using the new PSK= scheme, we need to use what the new name implies: pre _shared_ keys.=C2=A0= The new name implies that the server remembers a unique shared key for the= connection, which is server-side state per resumable connection.=C2=A0 If = we only store the PSK in the ticket, and go stateless on the server, then t= he server-side ticket decryption key again defeats strict forward secrecy.= =C2=A0 With a remembered server-side pre-shared secret, we can have a 0-RTT= resume with strict forward secrecy.=C2=A0 Is this already implied in the s= pec?=C2=A0 If so, the spec could be improved, by stating this explicitly.= =C2=A0 However, the current statement that 0-RTT does not provide forward s= ecrecy seems to be wrong in the case that we resume a 0-RTT connections wit= h a server-remembered PSK.


To have strict forward secrecy, given that the server al= ready has to have server-side state (the pre-shared key), I find the old se= ssion ID scheme more palatable than the new tickets.=C2=A0 The main point o= f session tickets was to eliminate the server-side session cache, wasn'= t it?


The cu= rrent ticket scheme is compatible with either a server-side database *or* h= aving self-contained
tickets which are encrypted with a server-si= de key. (This was also true for tickets, it's just that
you d= idn't bother with tickets if that is what you wanted). If you want a da= tabase, you just use
an identifier as the key name. The point is = to have a mechanism which accomodates either
design.
<= div>

I think the current spec doe= s not describe well enough how to implement secure 0-RTT infrastructure.=C2= =A0 Instead, it seems to recommend against using 0-RTT, with a pretty dire = warning about the insecurity of 0-RTT.

=

Well, the primary purpose of this warning isn= 9;t to warn about PFS. It's really to warn
about the replay i= ssue, which is unique to 0-RTT and which can't really be fixed
by proper implementation. The issue isn't that it's not possible = to have anti-replay
if you're willing to store server side st= ate, but rather how you respond to server-side state
loss. Moreov= er, the problems exist whether or not you use certificate-based
c= lient authentication.

I haven't thought this t= hrough in as much detail as I've thought through the
non-PSK = 0-RTT case, but I don't believe that PSK-resumption solves the
problems with replay. The basic issue is the same: what happens when
a server gets a connection attached to state which it doesn't hav= e. So,
what the attacker would do duplicate the ClientHello + PSK= and send one
copy to the true datacenter and one to another data= center that doesn't have
state. The right datacenter will pro= cess the 0-RTT handshake and the
wrong one will reject it, causin= g the client to fall back to 1-RTT and retransmit
the request. So= , you still get replay.

-Ekr

<= div>


--94eb2c0889dc9bcd2905263fe75b-- From nobody Sun Dec 6 12:30:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44B01B2B4F for ; Sun, 6 Dec 2015 12:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, T_RP_MATCHES_RCVD=-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 z7jZ6abN-XGu for ; Sun, 6 Dec 2015 12:30:15 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC881B2B4E for ; Sun, 6 Dec 2015 12:30:15 -0800 (PST) Received: by ioir85 with SMTP id r85so162980075ioi.1 for ; Sun, 06 Dec 2015 12:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G54/O/zt1bAxe2rUAqFZtd5Va0OPFCt5CZAk82jf6IY=; b=JgOzDtC9vQL0KnkvMmZ2N9dZHWJTMYTD01gIceeJDkW9bWjC1Re+k3az+dkgOVA3ij rdwjdpnkccaWmbWgGJCVQ0y4S/x50OZfyvjxbdSHmy7ysQNg7Hv7PYbVgGHLzjpBbH1g +5mkzJZj1xA81CmYtoLsKWU0EQdAh6KmjzexvREv7OGI7wIZsTHNVd/dmSjoURFvhcT1 PT55ECoq54MV9fvxflITX4M1Wg87ifIIf1k0i3IO1T8tuVtTPpYvcTUQCrOIG68EM7FO Zx5TndRecdZphC3ePRIhDMIE6JncXRPuYXwE1wFc2NxwDIYP229AcCiK1pqTXNzsw87Q Vn+g== 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=G54/O/zt1bAxe2rUAqFZtd5Va0OPFCt5CZAk82jf6IY=; b=f5Dy16QAoh24E4hXq3AZv9Vqp61oSEVlOr37q1CZjdZIEYISy+21ceYJ4SXbHTE/Q1 l2FpOfeBt9ztyUwu2Efxt6c9JQ1l9R4BMcCTuMH/VMuQSM2BvZijIx08T1bvObqy6FCQ tBlfmLTqkWV9GlqWTKY9ZRnGOXST5xtsZbbbvieUHwgks7nA3Clgdxao8SRybBwSlNXB EV+/1czgDfdcjuk3bJTuol5DZmn8+cVl2l24Q+gllsOplTg+19Y6b/FEwyIqKNfGix7b en1PtLGbB2e3f8peuLzAWQuNzx8ejPe1dpzBf94xpqnYlO6439cCH9m2RTJhGTYIxBRP o5+g== X-Gm-Message-State: ALoCoQn8HDjrqxDjzY9P3MkVSsLgW36JqKz4EUDuTvCcwxUuzvBRzbsugBDvZEOFWjCV21k26DXV MIME-Version: 1.0 X-Received: by 10.107.152.133 with SMTP id a127mr23863615ioe.60.1449433814658; Sun, 06 Dec 2015 12:30:14 -0800 (PST) Received: by 10.107.173.15 with HTTP; Sun, 6 Dec 2015 12:30:14 -0800 (PST) In-Reply-To: References: Date: Sun, 6 Dec 2015 12:30:14 -0800 Message-ID: From: Bill Cox To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1140e69ea647d20526409b6f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Forward secrecy with resumption, and 0-RTT security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 20:30:16 -0000 --001a1140e69ea647d20526409b6f Content-Type: text/plain; charset=UTF-8 On Sun, Dec 6, 2015 at 11:39 AM, Eric Rescorla wrote: > With PSK-DHE over 0-RTT, would we use the static DHE server share for the >> first resume flight? >> > > No. In All PSK-DHE modes, the PSK is used as SS. > That's cool. I need to re-read the spec more carefully. > >> You're talking about the single byte that indicates an empty session id? > That doesn't seem like > it's a big source of inefficiency. > Ah... I did not realize it is u8-length encoded. One byte bothers me a lot less. > > I guess another question is: Do we care about strong client authentication >> enough to support it in a 0-RTT world? The default solution when using TLS >> 1.3 is for companies that use security keys to never use 0-RTT >> authentication. That's not the end of the world, but I imagine that having >> to support 0-RTT for regular users, and forcing 1-RTT for employees and >> users who choose a higher level of security is going to be a complication. >> > > Yes, I think it's important, especially for WebRTC. > OK... one more spec to read. > >> I still think some more text describing 0-RTT implementation techniques >> would be a good thing. It really does read as if the spec is saying that >> servers SHOULD NOT support 0-RTT. I've never read a security warning like >> that which did not have a SHOULD NOT associated with it. Of course, I >> haven't read that many IETF specs yet :) >> > > I'll but it on my TODO list but I would definitely welcome a PR here. > > Thanks, > -Ekr > > I'll see if I can put together some text that would help me understand a bit better, though as you can see from my emails so far, writing is not my strong suit. Bill --001a1140e69ea647d20526409b6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Dec 6, 2015 at 11:39 AM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>
<= div>With PSK-DHE over 0-RTT, would we use the static DHE server share for t= he first resume flight?=C2=A0

=
No. In All PSK-DHE modes, the PSK is used as SS.

That's cool.=C2=A0 I ne= ed to re-read the spec more carefully.=C2=A0

You're talking about the single byte that indicates a= n empty session id? That doesn't seem like
it's a big sou= rce of inefficiency.

Ah... I did not realize it is u8-length encoded.=C2=A0 One byte bothers m= e a lot less.

=
I guess another = question is: Do we care about strong client authentication enough to suppor= t it in a 0-RTT world?=C2=A0 The default solution when using TLS 1.3 is for= companies that use security keys to never use 0-RTT authentication.=C2=A0 = That's not the end of the world, but I imagine that having to support 0= -RTT for regular users, and forcing 1-RTT for employees and users who choos= e a higher level of security is going to be a complication.

Yes, I think it's impor= tant, especially for WebRTC.

<= /div>
OK... one more spec to read.
=

I still think s= ome more text describing 0-RTT implementation techniques would be a good th= ing.=C2=A0 It really does read as if the spec is saying that servers SHOULD= NOT support 0-RTT.=C2=A0 I've never read a security warning like that = which did not have a SHOULD NOT associated with it.=C2=A0 Of course, I have= n't read that many IETF specs yet :)

I'll but it on my TODO list but I would de= finitely welcome a PR here.

Thanks,
-Ekr=

<= /blockquote>
I'll see if I can put together some text that would he= lp me understand a bit better, though as you can see from my emails so far,= writing is not my strong suit.

Bill=C2=A0
--001a1140e69ea647d20526409b6f-- From nobody Sun Dec 6 13:49:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB9F1B33DE for ; Sun, 6 Dec 2015 13:49:14 -0800 (PST) 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, 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 1WPY9xwcwfli for ; Sun, 6 Dec 2015 13:49:12 -0800 (PST) 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 B3BAF1B33DC for ; Sun, 6 Dec 2015 13:49:12 -0800 (PST) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id ECE7838F05; Sun, 6 Dec 2015 13:49:11 -0800 (PST) From: "Jim Schaad" To: "'Bryan A Ford'" , References: <11f501d12ed6$41150270$c33f0750$@augustcellars.com> <5663FE47.1050106@gmail.com> In-Reply-To: <5663FE47.1050106@gmail.com> Date: Sun, 6 Dec 2015 13:46:25 -0800 Message-ID: <00ed01d1306f$8ee4d6c0$acae8440$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQK2HzzDa6zorWW5wNKNhe+Y0Giw8AGkqSGknOdskxA= Archived-At: Subject: Re: [TLS] Analysis of encrypting the headers - what is the length X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 21:49:14 -0000 > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Bryan A Ford > Sent: Sunday, December 06, 2015 1:22 AM > To: tls@ietf.org > Subject: Re: [TLS] Analysis of encrypting the headers - what is the length > > On 12/4/15 9:56 PM, Jim Schaad wrote: > > I will start by re-iterating my initial position that I would prefer > > that the DTLS and TLS analysis is going to be the same in terms of > > masking the header information. So I decided to do some thought > > experiments about what happens if the length were to be encrypted and > > how many different situations does this not appear to help the situation. > > Why are you fixated on enumerating different situations where encrypting > headers doesn't help, while completely ignoring situations where it can help? > You could draw up an infinite list of scenarios in both categories. No security > provision will address every possible attack scenario - padding definitely doesn't > either! - but both header encryption and padding are complementary provisions > that each make attacks more difficult for attackers in different ways. Having a solid idea of what the limitations of a solution are can be extremely helpful in trying to determine if the solution solves the problem as presented. My understanding of the problem that you are trying to solve is to hid the length of the data by encrypting it. Knowing when this does and does not work is part and parcel of trying to do the evaluation of a solutions effectiveness and then being able to do an evaluation of the benefits and costs of such a solution. It might be helpful to have a more formal set of situations where the solution works so that it can be compared. If the solution of encrypting the header requires additional tactics as well, then it should be well understood that the encryption solution is, in itself, insufficient. Doing so would also allow for a better understanding of what other solutions can be used to address the same, or similar, problems potentially without the same costs. The question of whether padding does or does not solve the problem depends to a large extend on what the attack model you are using is. If the attack model requires that you know the exact length of the data involved, then doing a simple padding with random lengths of data, or padding out to a fixed boundary does solve the problem entirely. If the attack model is based on distinguishing very large and very small blocks of data, then padding can solve this by making all responses pad out to a very large size. Again one needs to look at the costs of this as always sending a large amount of data in response, most of which is padding, presents a problem for the network and potentially the devices sending and receiving the data (power consumption). One therefore needs to do tradeoffs of the solution vs the problems. I am assuming that your attack model more closely follows the first one presented, but given that you have never stated it in any sort of formal language that is at best a wild guess on my part. Jim > > B From nobody Sun Dec 6 14:55:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C8D1B34E6 for ; Sun, 6 Dec 2015 14:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, T_RP_MATCHES_RCVD=-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 IfIyhyjsDNpn for ; Sun, 6 Dec 2015 14:55:21 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1FD1B34E3 for ; Sun, 6 Dec 2015 14:55:21 -0800 (PST) Received: by igbxm8 with SMTP id xm8so71102367igb.1 for ; Sun, 06 Dec 2015 14:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XYry1+LjARvS/H4reHt/Lo3B62UQdgQEoJoV4v6hl+c=; b=Hcsl8q79NtvJf5utNKRX2Fac1R0mogTS4cPqYoQ9LNK1lHzb1p9VZZjS2F96YNneUC GE1GkYuLdGunGap5UE/p1dw8nIMCDHm7z0sSPI9ta5DfOYIAJO4xWv7aN857KxnjwqxN KZgwXDMsvYgW5iteJjn8C7jrzZZjcIfvqWREX1KlIz9FZXO9pGpuUKUPKAMZrDzU4Qba zf5AKEFoIkp8HNEIuui7x9KA8fQoOhcsBHCqTY54HxkNC7vbMOw/U56unqBJMrc25Yn3 AnMNupLmPQ7frsUMc5sprFaMB7Dj+7q7sW+En1RdfuZx5GCZV9bDKjW80qBnre/CNPPZ Ej/g== 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=XYry1+LjARvS/H4reHt/Lo3B62UQdgQEoJoV4v6hl+c=; b=UiqF86o49Od41wG5KmIj+080aU6HsoHmhY5+B9H4s1GgUzu79+2IxPWz4X9EN/YdCV dn39UPNgtJmnY0k1B9n6HsdGReoGKPQ3xJgS8NgAEEx4Y5w+Xi4+8R/uf4itqVLO/9X/ tJriJekvAShdO+2d9D7M6RFY06uLhLEBGG1s3nPRwYkA1+s1rem1p6EnPXDq0+6zFOaJ 5fta72ePg/xc6xTIh8JP4/vC4ZvulpQ0frFMFaLWmLYjQYxeEjOPJo4mZqYY8m27ifZS 87k/0+h0UBlevu6GYMxgqO4YIDmTwDP63L7wsG15VeS7/VjJk+ojdIoYJAbNTtVnikkS igVg== X-Gm-Message-State: ALoCoQlF4VQl5Cwz0z43Y/Qan+Gw1USuPYVc/7pT/w88R2M9dZYXKNNjf5q5bt1foC9EoM4y9wT2 MIME-Version: 1.0 X-Received: by 10.50.61.37 with SMTP id m5mr14295724igr.4.1449442520405; Sun, 06 Dec 2015 14:55:20 -0800 (PST) Received: by 10.107.173.15 with HTTP; Sun, 6 Dec 2015 14:55:20 -0800 (PST) In-Reply-To: References: Date: Sun, 6 Dec 2015 14:55:20 -0800 Message-ID: From: Bill Cox To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1135f3048d71dd052642a205 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Forward secrecy with resumption, and 0-RTT security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 22:55:22 -0000 --001a1135f3048d71dd052642a205 Content-Type: text/plain; charset=UTF-8 Just how strict do we want to be with forward secrecy? The choices I see are: 1) Avoid 0-RTT connections, and do only 1-RTT connections when we want strict forward secrecy and strong client authentication 2) Keep server-side state for decrypting each ticket, and issue new tickets on each connection, while avoiding 0-RTT replay to the same data center. 3) Give up on first flight forward secrecy, as well as client authentication for first flight data. If tickets are reused for multiple 0-RTT resumptions, then the earlier connections can be decrypted using whatever state the server keeps to decrypt later connections. I think option 1 simple and secure, but is too slow. The choice between 2) and 3) is a security vs cost and complexity trade-off. No new functionality is required to implement 1, 2, or 3, I think. It can be up to the implementation and application. Is it worth spelling out in the spec the gory details? I'm trying out some language for implementing 2, and the downsides for 1 and 3. Not sure if it belongs... Bill --001a1135f3048d71dd052642a205 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just how strict do we want to b= e with forward secrecy?=C2=A0 The choices I see are:

1) Avoid 0-RTT connections, = and do only 1-RTT connections when we want strict forward secrecy and stron= g client authentication
2) Keep server-side= state for decrypting each ticket, and issue new tickets on each connection= , while avoiding 0-RTT replay to the same data center.
3) Give up on first flight forward secrecy, as well as client a= uthentication for first flight data.

If tickets are reused for multiple 0-RTT res= umptions, then the earlier connections can be decrypted using whatever stat= e the server keeps to decrypt later connections.

I think option 1 simple and secu= re, but is too slow.=C2=A0 The choice between 2) and 3) is a security vs co= st and complexity trade-off.

No new functionality is required to implement 1, 2, = or 3, I think.=C2=A0 It can be up to the implementation and application.=C2= =A0 Is it worth spelling out in the spec the gory details?

I'm trying out so= me language for implementing 2, and the downsides for 1 and 3.=C2=A0 Not su= re if it belongs...

Bill
--001a1135f3048d71dd052642a205-- From nobody Sun Dec 6 15:00:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7261B34FC for ; Sun, 6 Dec 2015 15:00:45 -0800 (PST) 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 2y2O1mLV_6u6 for ; Sun, 6 Dec 2015 15:00:43 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4844A1B34FB for ; Sun, 6 Dec 2015 15:00:43 -0800 (PST) Received: by igcph11 with SMTP id ph11so63583614igc.1 for ; Sun, 06 Dec 2015 15:00:42 -0800 (PST) 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=i5SJ/X79lhyKQafwcF56vLY8Ov85bGTo/xqRwfrVNfA=; b=yE6PA3k6smQzKG2dnpk/zmddKLRW+dT15BUfjxW7FUtpID6U7w7p9erjfIKWmcEzhJ VyS9LXeStR87tLXdaow8lwKjjFuEbYnfAzLTnZ7NirJIxoK6J9I1Ls0nb1z0RAVDqs/Q K7m78kB4ZgLWAljfMCCUDta6dx9KtZmAppCJEMFl0Z0KxMf/G1BVptorm6RFZYQqMr9c O0bRAHMEgx+HojiZmgqxkvq1hJnFW3VVptJ8NrNAO0XWJxvyJQ2r41YM4m4d1YCLGf68 PUSIHh2QTzL+BTkVUk5RSowv8jBKFR3lPgESvNCJD1vwwdXYqD5eoLwIi6beAkzixw/o XmVA== X-Received: by 10.50.93.33 with SMTP id cr1mr12543944igb.18.1449442842642; Sun, 06 Dec 2015 15:00:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.37.140 with HTTP; Sun, 6 Dec 2015 15:00:23 -0800 (PST) In-Reply-To: References: From: Tony Arcieri Date: Sun, 6 Dec 2015 15:00:23 -0800 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=047d7b4140fcc211b5052642b59f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Forward secrecy with resumption, and 0-RTT security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 23:00:45 -0000 --047d7b4140fcc211b5052642b59f Content-Type: text/plain; charset=UTF-8 On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox wrote: > In the past, there were two cases: resumption using session IDs, and > resumption with session tickets. Using session IDs loses forward secrecy, > because the server always has session keys in a session cache, which could > be used to decrypt the prior sessions. Using tickets did not work either, > because the server always kept a ticket decryption key which could be used > to decrypt all resumed sessions since the key was last rotated. > > My first question is: Do we care? > At least for session tickets, I don't care. There's a simple enough way to solve that problem: rotate the session ticket key every few days. -- Tony Arcieri --047d7b4140fcc211b5052642b59f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Dec 6, 2015 at 6:50 AM, Bill Cox <waywardgeek@google.com> wrote:

In the past, there were two cases: resumption using session IDs, a= nd resumption with session tickets.=C2=A0 Using session IDs loses forward s= ecrecy, because the server always has session keys in a session cache, whic= h could be used to decrypt the prior sessions.=C2=A0 Using tickets did not = work either, because the server always kept a ticket decryption key which c= ould be used to decrypt all resumed sessions since the key was last rotated= .


My= first question is: Do we care?

At least for session tickets, I don't care. There's a = simple enough way to solve that problem: rotate the session ticket key ever= y few days.
=C2=A0
--
Tony Arcieri
--047d7b4140fcc211b5052642b59f-- From nobody Sun Dec 6 15:07:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174521B351B for ; Sun, 6 Dec 2015 15:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, T_RP_MATCHES_RCVD=-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 0mL7j0L5SNgz for ; Sun, 6 Dec 2015 15:07:32 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5F11B3519 for ; Sun, 6 Dec 2015 15:07:30 -0800 (PST) Received: by iouu10 with SMTP id u10so168260570iou.0 for ; Sun, 06 Dec 2015 15:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O5p6xeu9ROTLcVWDTrFNxpcQQunDsoAUb1W7TencWoQ=; b=mbbie0KtGvtGGdz5/iUqohSR+To2jBdtlu/TrPDsPDpulBuiBmxgzTd4v/5ArHJMkU jUk70FDwoLoi8dlYotMBDy1ZsV1qs/hlP2DBcCqGy00QGDPRMlyad/B/9q+Mx6PEINK2 rAc7fq34lPaBPNNEalnuKvqZTt6iYnXDyJiv7OeoTAeSNixOQgSivJTbzTqOb8w/wTwB dG5pZ4rDumQqu7N9YvJ/0CB6hk/KgkAZej0Q1Q2tG5ZfQl8MwCDs2GgYECg81tya4CHf 44WSriiwZkl6v6LTRLTgS2eiz2l1sgEvCyoxrHiy7xNV9ukTy6A7vs5edkZsrgssLeVH 0ikQ== 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=O5p6xeu9ROTLcVWDTrFNxpcQQunDsoAUb1W7TencWoQ=; b=SCbXxccYiPWwZlJq3MhtDDNeZQkkbE0RrYJn/rHm30rISjdQ1PY6qwAYf/OEQWYgNM cAczJykOJeogVTCbZsLpkDRFVEZ1MlFqRDpl6XbA6aMYdaeLu+J8tbNO/Kqd7PNCFupn WQ0jTeLQkApwJOcEQg53Vbo4PdIZD0ep/dtsWHRpVHd02z1puPVN8wkiEnwM8Xp2M4Mc ov7cqCERQxp4o9IT6zSWUuOKVbrnqfZlQJ4G+8oLpQr03yoNfcMJQ0+RR3BWgcoW4Txc FWxu9gfYeqIzS5/68NNMIa8Hf2x/taelstco8440Yvpu0c43vgUw+UkLT8dqyCTlVSxD I+7g== X-Gm-Message-State: ALoCoQlbSvc44XXuY2kqsiov3vCLjDXt3rOfXKJjjyJb9lO3zQZ4vpjf7/2LbD85UwUD/s3RNduP MIME-Version: 1.0 X-Received: by 10.107.25.81 with SMTP id 78mr25753868ioz.127.1449443249658; Sun, 06 Dec 2015 15:07:29 -0800 (PST) Received: by 10.107.173.15 with HTTP; Sun, 6 Dec 2015 15:07:29 -0800 (PST) In-Reply-To: References: Date: Sun, 6 Dec 2015 15:07:29 -0800 Message-ID: From: Bill Cox To: Tony Arcieri Content-Type: multipart/alternative; boundary=001a113ff00a04f89b052642ce08 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Forward secrecy with resumption, and 0-RTT security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Dec 2015 23:07:33 -0000 --001a113ff00a04f89b052642ce08 Content-Type: text/plain; charset=UTF-8 On Sun, Dec 6, 2015 at 3:00 PM, Tony Arcieri wrote: > On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox wrote: > >> In the past, there were two cases: resumption using session IDs, and >> resumption with session tickets. Using session IDs loses forward secrecy, >> because the server always has session keys in a session cache, which could >> be used to decrypt the prior sessions. Using tickets did not work either, >> because the server always kept a ticket decryption key which could be used >> to decrypt all resumed sessions since the key was last rotated. >> >> My first question is: Do we care? >> > > At least for session tickets, I don't care. There's a simple enough way to > solve that problem: rotate the session ticket key every few days. > > -- > Tony Arcieri > I tend to agree. The difference between 100% forward secrecy and the old weaker version where sessions become forward secure after a few days is not a huge deal. What do you think about client authentication for first flight data? It is possible, but painful to implement. Bill --001a113ff00a04f89b052642ce08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Dec 6, 2015 at 3:00 PM, Tony Arcieri <bascule@gmail.com>= wrote:
On Sun, Dec 6, 2015 = at 6:50 AM, Bill Cox <waywardgeek@google.com> wrote:

In the past, there were t= wo cases: resumption using session IDs, and resumption with session tickets= .=C2=A0 Using session IDs loses forward secrecy, because the server always = has session keys in a session cache, which could be used to decrypt the pri= or sessions.=C2=A0 Using tickets did not work either, because the server al= ways kept a ticket decryption key which could be used to decrypt all resume= d sessions since the key was last rotated.


My first question is: Do we care?


At least for s= ession tickets, I don't care. There's a simple enough way to solve = that problem: rotate the session ticket key every few days.
=C2=A0
<= span class=3D"HOEnZb">--
Tony Arcieri
<= /div>

I tend to agree.=C2= =A0 The difference between 100% forward secrecy and the old weaker version = where sessions become forward secure after a few days is not a huge deal.

What do= you think about client authentication for first flight data?=C2=A0 It is p= ossible, but painful to implement.

Bill
--001a113ff00a04f89b052642ce08-- From nobody Mon Dec 7 03:09:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7861A21BC for ; Mon, 7 Dec 2015 03:09:55 -0800 (PST) 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 C-cSH-Ruo0wM for ; Mon, 7 Dec 2015 03:09:53 -0800 (PST) Received: from filtteri2.pp.htv.fi (filtteri2.pp.htv.fi [213.243.153.185]) by ietfa.amsl.com (Postfix) with ESMTP id AF2B51A21B0 for ; Mon, 7 Dec 2015 03:09:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri2.pp.htv.fi (Postfix) with ESMTP id 963A619C03E for ; Mon, 7 Dec 2015 13:09:51 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri2.pp.htv.fi [213.243.153.185]) (amavisd-new, port 10024) with ESMTP id rM1Ix6TpzAWS for ; Mon, 7 Dec 2015 13:09:51 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id 7006C5BC003 for ; Mon, 7 Dec 2015 13:09:51 +0200 (EET) Date: Mon, 7 Dec 2015 13:09:48 +0200 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20151207110948.GA3801@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Subject: [TLS] TLS 1.3 ServerConfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Dec 2015 11:09:55 -0000 This came up while writing serializers/deserializers for various TLS 1.2 and 1.3 stuff... Didn't see issues/pull requests for any of these... 1) ServerConfiguration has field early_data_type, which is of type EarlyDataType. I don't see definition of that type anywhere. I guess it was missed when that type was removed? 2) If ServerConfiguration contains an unknown extension, how should the client behave? Ignore the unknown extension, ignore the entiere ServerConfiguration or send a fatal alert? 3) Could the group and server_key fields be combined into a single field of type KeyShareEntry? The layout would be identical, and one could clearly reuse KeyShareEntry parsing (especially considering some groups have 2-byte interrior length fields as opposed to 1-byte). BTW: The new TLS 1.3 extensions don't have even test values assigned. The values I put in were: - early_data: 13000 (0x32C8) - pre_shared_key: 13001 (0x32C9) - key_share: 13002 (0x32CA) - cookie: 13003 (0x32CB) -Ilari From nobody Mon Dec 7 05:37:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A6A1B32AC for ; Mon, 7 Dec 2015 05:37:04 -0800 (PST) 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, HTML_MESSAGE=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 1gVMB1qTB4ii for ; Mon, 7 Dec 2015 05:37:02 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87EC41B32AA for ; Mon, 7 Dec 2015 05:37:02 -0800 (PST) Received: by ykdr82 with SMTP id r82so193627933ykd.3 for ; Mon, 07 Dec 2015 05:37:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=K8GWsLsVZyZbwZ49c+PJHedcRcfZfQXYNfj/skjg4s8=; b=Z+axKTF6Kc27vjGsScykZyoufc2Zy/l/nxxBM2Yhyf9iJiWgV/jvodU0nwAizhtE4Z gnEjNEGXAvKjU7gsYRIgWmbE6oK2CU0E0+tJSwMf6WZAJJ9+bo4xRYjPlfwXkmM2Zw5A w32UQufHC+5T55ZZA7foaKT+0SLLTWlN1GuDwHye/NTDFe98ps2mVw3QUY0CeofOcJLW IwBHgTTUM6HVnDgB15WvkIKO47ZApWC/0JpG5Gm64HQJDwUCOtIzH/1XVvjjSILafjnP DuQxa2wA8skUGF/nFBd3DekjuaRcRdITTtOB7+id8PWapImTAut8USh9v5UQg3cg7AJ6 I9Hg== 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=K8GWsLsVZyZbwZ49c+PJHedcRcfZfQXYNfj/skjg4s8=; b=RejcpUv/OjxKveKwMLNdBaBHr9lgVg4RbJDoli8bzR8ud3qRBphX2iI8cB7mUnL01H HxulOif5ng6yxJhDdHczWeBfOF/dlYoqx6RR+4nzvZ3W76jy9Wvlr6/evVKLjPKpfYWF g4BoAp45/m7MXLMkGpr55ZAGmEnaI8GW7G9ko2RXCYrjaXFKG/zUH150DRidtjxL6eAs Mql6hMOm9V9qDPuQ+uI7fJbMu/09EYi1vfsQr+6gNaLEHltdeUXg2xmWM5QgpkR6e217 edCbIQNiJOHRGebxyGf1nmgioDAJhgZRzNZgjnnh7Pj/EtHewFwJCMuAS/hrvNrd5BWg UrFg== X-Gm-Message-State: ALoCoQljDxeRk0NJFKXa9vxDuL4d7UdhE+jD2QGho2bIvp1M5IdfDpMNxdVhSTj7Aph/5o5QwaFZ X-Received: by 10.13.218.198 with SMTP id c189mr24568474ywe.165.1449495421846; Mon, 07 Dec 2015 05:37:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Mon, 7 Dec 2015 05:36:22 -0800 (PST) In-Reply-To: <20151207110948.GA3801@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151207110948.GA3801@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Mon, 7 Dec 2015 05:36:22 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c08192ab93ad505264ef3de Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 ServerConfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Dec 2015 13:37:04 -0000 --94eb2c08192ab93ad505264ef3de Content-Type: text/plain; charset=UTF-8 On Mon, Dec 7, 2015 at 3:09 AM, Ilari Liusvaara wrote: > This came up while writing serializers/deserializers for various TLS > 1.2 and 1.3 stuff... Didn't see issues/pull requests for any of > these... > > 1) ServerConfiguration has field early_data_type, which is of type > EarlyDataType. I don't see definition of that type anywhere. I > guess it was missed when that type was removed? > Oops. This got removed. Will re-add. > 2) If ServerConfiguration contains an unknown extension, how should > the client behave? Ignore the unknown extension, ignore the entiere > ServerConfiguration or send a fatal alert? > Ignore the unknown extension seems consistent. 3) Could the group and server_key fields be combined into a single > field of type KeyShareEntry? The layout would be identical, and > one could clearly reuse KeyShareEntry parsing This is a great idea. I will do it! > (especially > considering some groups have 2-byte interrior length fields > as opposed to 1-byte). > I noticed this in my implementation as well. I actually propose to just remove that extra interior length field. Can't see any reason to keep it. BTW: The new TLS 1.3 extensions don't have even test values > assigned. The values I put in were: > - early_data: 13000 (0x32C8) > - pre_shared_key: 13001 (0x32C9) > - key_share: 13002 (0x32CA) > - cookie: 13003 (0x32CB) > I suggest 40-44 in the order you list above, since we've agreed not to have specified ranges any more. -Ekr > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c08192ab93ad505264ef3de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 7, 2015 at 3:09 AM, Ilari Liusvaara <<= a href=3D"mailto:ilariliusvaara@welho.com" target=3D"_blank">ilariliusvaara= @welho.com> wrote:
This came up while wri= ting serializers/deserializers for various TLS
1.2 and 1.3 stuff... Didn't see issues/pull requests for any of
these...

1) ServerConfiguration has field early_data_type, which is of type
EarlyDataType. I don't see definition of that type anywhere. I
guess it was missed when that type was removed?

Oops. This got removed. Will re-add.

=C2= =A0
2) If ServerConfiguration contains an unknown extension, how should
the client behave? Ignore the unknown extension, ignore the entiere
ServerConfiguration or send a fatal alert?

<= div>Ignore the unknown extension seems consistent.


3) Could the group and server_key fields be combined into a single
field of type KeyShareEntry? The layout would be identical, and
one could clearly reuse KeyShareEntry parsing

This is a great idea. I will do it!
=C2=A0

=C2=A0
(especially
considering some groups have 2-byte interrior length fields
as opposed to 1-byte).

I noticed this i= n my implementation as well. I actually propose to just
remove th= at extra interior length field. Can't see any reason to keep
= it.=C2=A0


BTW: The new TLS 1.3 extensions don't have even test values
assigned. The values I put in were:
- early_data: 13000 (0x32C8)
- pre_shared_key: 13001 (0x32C9)
- key_share: 13002 (0x32CA)
- cookie: 1300= 3 (0x32CB)

I suggest 40-44 in the order= you list above, since we've agreed not to have
specified ran= ges any more.

-Ekr



=C2=A0


-Ilari

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

--94eb2c08192ab93ad505264ef3de-- From nobody Mon Dec 7 20:25:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9484F1B2BD3 for ; Mon, 7 Dec 2015 19:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 O3atvhKDKP0b for ; Mon, 7 Dec 2015 19:51:05 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB4E1ACE96 for ; Mon, 7 Dec 2015 19:51:05 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5923A180477; Mon, 7 Dec 2015 19:49:04 -0800 (PST) To: rlb@ipv.sx, martin.thomson@gmail.com, alfredo@pironti.eu, agl@google.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, sean+ietf@sn3rd.com, joe@salowey.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151208034904.5923A180477@rfc-editor.org> Date: Mon, 7 Dec 2015 19:49:04 -0800 (PST) Archived-At: X-Mailman-Approved-At: Mon, 07 Dec 2015 20:25:30 -0800 Cc: rap1011@ksu.edu, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Editorial Errata Reported] RFC7568 (4561) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2015 03:51:06 -0000 The following errata report has been submitted for RFC7568, "Deprecating Secure Sockets Layer Version 3.0". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7568&eid=4561 -------------------------------------- Type: Editorial Reported by: Richard Petrie Section: 1. Original Text ------------- Since it was released in 1996, the SSLv3 protocol [RFC6101] has been subject to a long series of attacks, both on its key exchange mechanism and on the encryption schemes it supports. Despite being replaced by TLS 1.0 [RFC2246] in 1999, and subsequently TLS 1.1 in 2002 [RFC4346] and 1.2 in 2006 [RFC5246], availability of these replacement versions has not been universal. As a result, many implementations of TLS have permitted the negotiation of SSLv3. The predecessor of SSLv3, SSL version 2, is no longer considered sufficiently secure [RFC6176]. SSLv3 now follows. Corrected Text -------------- Since it was released in 1996, the SSLv3 protocol [RFC6101] has been subject to a long series of attacks, both on its key exchange mechanism and on the encryption schemes it supports. Despite being replaced by TLS 1.0 [RFC2246] in 1999, and subsequently TLS 1.1 in 2006 [RFC4346] and 1.2 in 2008 [RFC5246], availability of these replacement versions has not been universal. As a result, many implementations of TLS have permitted the negotiation of SSLv3. The predecessor of SSLv3, SSL version 2, is no longer considered sufficiently secure [RFC6176]. SSLv3 now follows. Notes ----- TLS 1.1 was first drafted in 2002, but not published until 2006. Similarly, TLS 1.2 was drafted in 2006, but not published until 2008. 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. -------------------------------------- RFC7568 (draft-ietf-tls-sslv3-diediedie-03) -------------------------------------- Title : Deprecating Secure Sockets Layer Version 3.0 Publication Date : June 2015 Author(s) : R. Barnes, M. Thomson, A. Pironti, A. Langley Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Dec 7 20:25:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EEF1B2BF7 for ; Mon, 7 Dec 2015 20:05:24 -0800 (PST) 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 zxGyIEBqGzsp for ; Mon, 7 Dec 2015 20:05:23 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC52F1B2BF6 for ; Mon, 7 Dec 2015 20:05:22 -0800 (PST) Received: by igcph11 with SMTP id ph11so88410802igc.1 for ; Mon, 07 Dec 2015 20:05:22 -0800 (PST) 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=67qW/231dCLywrP+rYropTuNJlIYWCueKb5n4zWcdqY=; b=tpc8jcRfKyoaYgqZ7B4An58jZMj5I/BVaywDZh4O0R98u4mX4rx+LSn/no0NTrEsOO VTUUvR8xMrMhuWAmAP1EGifXdu4g84Rx8AzRlwze4TagTzbnU7UQLte04cM0jdbNb+WP Ay49+nGVYFweMt5uGXtqsaOoa2qNYdVTjoGdbp0ThtPYxVVYhUVmBAgQImFnz7JPZPL8 EoYhmMvgO/RhfMV+DEw/KT4/ag2sX21Vok2szmFyfZaf302XFg2sCElXlT7hYzni2W2l 6q/8uukJnu8hGEB58Eudt0p5X5ZstS/yrme2J89w/OLWQEJD87DSyMAvYhSZLWjKIikv bv0Q== MIME-Version: 1.0 X-Received: by 10.50.183.11 with SMTP id ei11mr2099591igc.94.1449547522141; Mon, 07 Dec 2015 20:05:22 -0800 (PST) Received: by 10.36.155.139 with HTTP; Mon, 7 Dec 2015 20:05:22 -0800 (PST) In-Reply-To: <20151208034904.5923A180477@rfc-editor.org> References: <20151208034904.5923A180477@rfc-editor.org> Date: Tue, 8 Dec 2015 15:05:22 +1100 Message-ID: From: Martin Thomson To: RFC Errata System Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Mon, 07 Dec 2015 20:25:30 -0800 Cc: Richard Barnes , sean+ietf@sn3rd.com, rap1011@ksu.edu, Adam Langley , Kathleen Moriarty , "tls@ietf.org" , Alfredo Subject: Re: [TLS] [Editorial Errata Reported] RFC7568 (4561) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2015 04:05:24 -0000 On 8 December 2015 at 14:49, RFC Errata System wrote: > TLS 1.1 was first drafted in 2002, but not published until 2006. Similarly, TLS 1.2 was drafted in 2006, but not published until 2008. The date on the documents are indeed wrong. I recommend holding for document update. From softeng979@gmail.com Mon Dec 7 13:00:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374F41A883C for ; Mon, 7 Dec 2015 13:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 QWzjllgH9Dcb for ; Mon, 7 Dec 2015 13:00:55 -0800 (PST) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E853B1A87A0 for ; Mon, 7 Dec 2015 13:00:54 -0800 (PST) Received: by ioc74 with SMTP id 74so307420ioc.2 for ; Mon, 07 Dec 2015 13:00:54 -0800 (PST) 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=2b0rgWTHaE9bmAwe0z0hLUx9Y/ALC8m0neu4e5TecKI=; b=eW2kgKYc1mkSKydidbvQWPxaM+0IdDCHP4lgEhlCYgc3r7DvF/teVTUXc4MNEdUha0 x3c20b/Um/wmyIe1jtUs4FtVwhaZZQsEMK1W9H0LmUnWXb++d8JzzG6t/Bo2kxhGQCcM VRz+b5lpJyhO97HSakMGmP3eBLp8o2KzhzezPzQUGp5YwvGMruvDyQ13FK7BpCRkSsa3 rHhvWFScaPWatCM3DVWsKCZptTFly0BLMnJHchE925Btc2XqCS/bLiNiUsN3aW2eEOaP BOGUkPYbf2yQYiy2G0HiFeL6olUuF1E5ESATxrWQxSFJIbB8mZBiP3cLeKdmXU1fXVc1 GtPg== MIME-Version: 1.0 X-Received: by 10.50.109.136 with SMTP id hs8mr378601igb.93.1449522054279; Mon, 07 Dec 2015 13:00:54 -0800 (PST) Received: by 10.107.146.138 with HTTP; Mon, 7 Dec 2015 13:00:54 -0800 (PST) Date: Mon, 7 Dec 2015 15:00:54 -0600 Message-ID: From: Software Engineer 979 To: tls@ietf.org Content-Type: multipart/alternative; boundary=089e013a213e23b7cf052655274c Archived-At: X-Mailman-Approved-At: Mon, 07 Dec 2015 20:26:40 -0800 Subject: [TLS] TLS Record Size Limitation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Dec 2015 21:01:46 -0000 --089e013a213e23b7cf052655274c Content-Type: text/plain; charset=UTF-8 Hello, I'm currently developing an data transfer application using OpenSSL. The application is required to securely transfer large amounts of data over a low latency/high bandwidth network. The data being transferred lives in a 3rd part application that uses 1 MB buffer to transfer data to my application. When I hook OpenSSL into my application I notice an appreciable decline in network throughput. I've traced the issue the default TLS record size of 16K. The smaller record size causes the 3rd party application's buffer to be segmented into 4 16K buffers per write and the resulting overhead considerably slows things down. I've since modified the version of OpenSSL that I'm using to support an arbitrary TLS record size allowing OpenSSL to scale up to 1MB or larger TLS record size. Since this change, my network throughput has dramatically increased (187% degradation down to 33%). I subsequently checked the TLS RFC to determine why a 16K record size was being used, and all could find was the following: length The length (in bytes) of the following TLSCompressed.fragment. The length MUST NOT exceed 2^14 + 1024. The language here is pretty explicit stating that the length must not exceed 16K (+ some change).Does anyone know the reason for this? Is there a cryptographic reason why we shouldn't exceed this message size? Based on my limited experiment, it would appear that a larger record size would benefit low latency/high bandwidth networks. --089e013a213e23b7cf052655274c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

I'm currently developing an data transf= er application using OpenSSL. The application is required to securely trans= fer large amounts of data over a low latency/high bandwidth network. The da= ta being transferred lives in a 3rd part application that uses 1 MB buffer = to transfer data to my application. When I hook OpenSSL into my application= I notice an appreciable decline in network throughput. I've traced the= issue the default TLS record size of 16K. The smaller record size causes t= he 3rd party application's buffer to be segmented into 4 16K buffers pe= r write and the resulting overhead considerably slows things down. I've= since modified the version of OpenSSL that I'm using to support an arb= itrary TLS record size allowing OpenSSL to scale up to 1MB or larger TLS re= cord size. Since this change, my network throughput has dramatically increa= sed (187% degradation down to 33%).=C2=A0

I subseq= uently checked the TLS RFC to determine why a 16K record size was being use= d, and all could find was the following:

=
length
      The length (in bytes) of the following TLSCompressed.fragment.=C2=A0<=
/pre>
=C2=A0 =C2=A0 =C2=A0 The leng=
th MUST NOT exceed 2^14 + 1024.

The languag=
e here is pretty explicit stating that the length must not exceed 16K (+ so=
me change).Does anyone know the reason for this? Is there a cryptographic r=
eason why we shouldn't exceed this message size? Based on my limited ex=
periment, it would appear that a larger record size would benefit low laten=
cy/high bandwidth networks.
<= div>
--089e013a213e23b7cf052655274c-- From nobody Tue Dec 8 00:50:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E0B1A90A6 for ; Tue, 8 Dec 2015 00:50:04 -0800 (PST) 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 FDlGJx6atkfw for ; Tue, 8 Dec 2015 00:50:02 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79CE11A90A2 for ; Tue, 8 Dec 2015 00:50:02 -0800 (PST) Received: by qgea14 with SMTP id a14so10484604qge.0 for ; Tue, 08 Dec 2015 00:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=RldAzaoFE6ucjL6RqEfkV9j047UOUIEgHy6k5OCcNbE=; b=0nNxenNjid6SvOAih0oi3+mswYQAY3CjANdRrUfD81O7r0pOpqJkZSWJ4whyY05fFZ ak7UZnpd6kygKBA553RA7DU19gak5z5aGBagpYF9cAQ91Q8hVAxYWNcW1awcL8r57EVG uz7Sl/7Il1x0j3B50Z9K39G0k1MCTr4BbMqvJaWtaHVw6jKmHpQYxpzq7uwjkyJnC1CM bcfVXzLPXR2A5KZBzSCnjzuOX9rHdUqD8pwF/8Kw9nBzK94fKIcwfIY5Rae9pzHUI5hP W7qz76FJF5XJPuOgBF9hqVOKVOOveBTRu+cy2ZTFKn+kahHgB3rpZxqlZwMdSTmkoMYw miZA== X-Received: by 10.140.27.228 with SMTP id 91mr3041958qgx.78.1449564601519; Tue, 08 Dec 2015 00:50:01 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id f7sm1086898qkb.7.2015.12.08.00.50.00 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 08 Dec 2015 00:50:00 -0800 (PST) From: Dave Garrett To: Software Engineer 979 Date: Tue, 8 Dec 2015 03:49:59 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201512080349.59635.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS Record Size Limitation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2015 08:50:04 -0000 On Monday, December 07, 2015 04:00:54 pm Software Engineer 979 wrote: > Hello, > > I'm currently developing an data transfer application using OpenSSL. The > application is required to securely transfer large amounts of data over a > low latency/high bandwidth network. The data being transferred lives in a > 3rd part application that uses 1 MB buffer to transfer data to my > application. When I hook OpenSSL into my application I notice an > appreciable decline in network throughput. I've traced the issue the > default TLS record size of 16K. The smaller record size causes the 3rd > party application's buffer to be segmented into 4 16K buffers per write and > the resulting overhead considerably slows things down. I've since modified > the version of OpenSSL that I'm using to support an arbitrary TLS record > size allowing OpenSSL to scale up to 1MB or larger TLS record size. Since > this change, my network throughput has dramatically increased (187% > degradation down to 33%). > > I subsequently checked the TLS RFC to determine why a 16K record size was > being used, and all could find was the following: > > length > The length (in bytes) of the following TLSCompressed.fragment. > > The length MUST NOT exceed 2^14 + 1024. > > The language here is pretty explicit stating that the length must not > exceed 16K (+ some change).Does anyone know the reason for this? Is there a > cryptographic reason why we shouldn't exceed this message size? Based on my > limited experiment, it would appear that a larger record size would benefit > low latency/high bandwidth networks. Well, the length field is 16-bit, so 2^16 is the hard upper limit for record format compatibility. (I don't personally know why it's less than that here, offhand) A TLS extension to negotiate max length might be viable. The handshake would have to keep to the old limits for backwards compatibility, but after that records could use a larger field (or add a multiplier to use 16-bit to cover larger sizes with padding as-needed). Dave From nobody Tue Dec 8 01:04:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816361A9101 for ; Tue, 8 Dec 2015 01:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4inBUCRFGjkS for ; Tue, 8 Dec 2015 01:04:06 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC281A9100 for ; Tue, 8 Dec 2015 01:04:05 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-4b-56669d03906e Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 62.6C.05149.30D96665; Tue, 8 Dec 2015 10:04:03 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.72]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Tue, 8 Dec 2015 10:03:39 +0100 From: John Mattsson To: "TLS@ietf.org" Thread-Topic: New Version Notification for draft-mattsson-tls-ecdhe-psk-aead-03.txt Thread-Index: AQHRMZRg1HPJxqsFKU+gu59ZioJKOJ7Ay4GA Date: Tue, 8 Dec 2015 09:03:38 +0000 Message-ID: References: <20151208084228.3383.88998.idtracker@ietfa.amsl.com> In-Reply-To: <20151208084228.3383.88998.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7hy7z3LQwgxdt8hafzncxOjB6LFny kymAMYrLJiU1J7MstUjfLoEr48Dn5ywFc+QqHv3ezdTAuEO2i5GTQ0LARKL36wNGCFtM4sK9 9WxdjFwcQgKHGSUe7F4J5SxilFgzu5EdpIpNwEBi7p4GoAQHh4iAosSnz9kgYWGBEIm+cxdY QGwRgVCJDQ3PmCFsI4m9H4+wgtgsAioSrcsvgdXwCphL/Hh7DKxGSMBB4tdCkHoODk4BR4kl 78BKGIHu+X5qDROIzSwgLnHryXwmiDsFJJbsOc8MYYtKvHz8D2y8qICexMFPK1lBxkgIKElM 25oGYjILaEqs36UPMcVa4sHF3awQtqLElO6H7BDHCEqcnPmEZQKj+Cwky2YhdM9C0j0LSfcs JN0LGFlXMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgTG1MEtvw12ML587niIUYCDUYmH1+B6 apgQa2JZcWXuIUYJDmYlEV7eWWlhQrwpiZVVqUX58UWlOanFhxilOViUxHmbmR6ECgmkJ5ak ZqemFqQWwWSZODilGhhXKdybIrsjVEthtWao7Kc56w7yOL3P0ZCOq5+fvVO+Ie3It9zO99xX HD+qP6s6vZbvsJFyI2sKa2Z4QeYX/fj4yE15VQXHryXY/28yDd8VXl34uaeeJ2X+I1frXouD J693vnm0a6v/O2+PFTOrfuhW1PDWPfC4Pt/s5U2fwkMZt/0Wl+Sy71JiKc5INNRiLipOBAB5 Xq/LpQIAAA== Archived-At: Subject: [TLS] FW: New Version Notification for draft-mattsson-tls-ecdhe-psk-aead-03.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: Tue, 08 Dec 2015 09:04:07 -0000 SGksDQoNCldlIGhhdmUgdXBsb2FkZWQgdmVyc2lvbiAwMyBvZiBkcmFmdC1tYXR0c3Nvbi10bHMt ZWNkaGUtcHNrLWFlYWQuIFJ1c3MNCnBvaW50ZWQgb3V0IHRoYXQgdGhlIGRvY3VtZW50IHdhcyB0 b3RhbGx5IHBvaW50ZWQgdG8gVExTIDEuMiBhbmQgdGhhdCBpdA0KbWFkZSBzZW5zZSB0byBjb3Zl ciBib3RoIFRMUyAxLjIgYW5kIFRMUyAxLjMuIFdlIGFncmVlZC4NCg0KVGhlIHVwZGF0ZWQgdmVy c2lvbiByZWZlcnMgdG8gVExTIDEuMyBbSS1ELmlldGYtdGxzLXRsczEzXSBhcyB3ZWxsIGFzIERU TFMNCjEuMiBbUkZDNjM0N10uIEl0IHBvaW50cyBvdXQgdGhlIHJlbGV2YW50IGNoYW5nZXMgYmV0 d2VlbiBUTFMgMS4yIGFuZCBUTFMNCjEuMywgaS5lLiB0aGUga2V5IGRlcml2YXRpb24gYW5kIHRo ZSBub25jZSBjb25zdHJ1Y3Rpb24uIEFtIEkgbWlzc2luZw0Kc29tZXRoaW5nIGVsc2U/DQoNCuKA nFdoZW4gdXNlZCBpbiBUTFMgMS4yLCB0aGUga2V5aW5nIG1hdGVyaWFsIGlzIGRlcml2ZWQgYXMg ZGVzY3JpYmVkIGluDQpbUkZDNTQ4OV0gYW5kIFtSRkM1MjQ2XSBhbmQgbm9uY2VzIGFyZSBjb25z dHJ1Y3RlZCBhcyBkZXNjcmliZWQgaW4NCltSRkM1Mjg4XSwgYW5kIFtSRkM2NjU1XS4gV2hlbiB1 c2VkIGluIFRMUyAxLjMsIHRoZSBrZXlpbmcgbWF0ZXJpYWwNCmlzIGRlcml2ZWQgYXMgZGVzY3Jp YmVkIGluIFtJLUQuaWV0Zi10bHMtdGxzMTNdLCBhbmQgdGhlIG5vbmNlcyBhcmUNCmNvbnN0cnVj dGVkIGFzIGRlc2NyaWJlZCBpbiBbSS1ELmlldGYtdGxzLXRsczEzXS7igJ0NCg0KM0dQUCBub3cg Zm9ybWFsbHkgaGFzIGEgZGVwZW5kZW5jeSBvbiBkcmFmdC1tYXR0c3Nvbi10bHMtZWNkaGUtcHNr LWFlYWQsDQpvciBhdCBsZWFzdCB0aGUgY2lwaGVyIHN1aXRlcyBUTFNfRUNESEVfUFNLX1dJVEhf QUVTXzEyOF9HQ01fU0hBMjU2IGFuZA0KVExTX0VDREhFX1BTS19XSVRIX0FFU18yNTZfR0NNX1NI QTM4NC4NCg0KQ2hlZXJzLA0KSm9obg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkpPSE4gTUFUVFNTT04NCk1TYyBF bmdpbmVlcmluZyBQaHlzaWNzLCBNU2MgQnVzaW5lc3MgQWRtaW5pc3RyYXRpb24gYW5kIEVjb25v bWljcw0KRXJpY3Nzb24gSUVURiBTZWN1cml0eSBDb29yZGluYXRvcg0KU2VuaW9yIFJlc2VhcmNo ZXIsIFNlY3VyaXR5DQoNCg0KDQoNCg0KDQpPbiAwOC8xMi8xNSAwOTo0MiwgImludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCndyb3RlOg0KDQo+DQo+ QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1hdHRzc29uLXRscy1lY2RoZS1wc2stYWVhZC0w My50eHQNCj5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEpvaG4gTWF0dHNzb24g YW5kIHBvc3RlZCB0byB0aGUNCj5JRVRGIHJlcG9zaXRvcnkuDQo+DQo+TmFtZToJCWRyYWZ0LW1h dHRzc29uLXRscy1lY2RoZS1wc2stYWVhZA0KPlJldmlzaW9uOgkwMw0KPlRpdGxlOgkJRUNESEVf UFNLIHdpdGggQUVTLUdDTSBhbmQgQUVTLUNDTSBDaXBoZXIgU3VpdGVzIGZvciBUcmFuc3BvcnQN Cj5MYXllciBTZWN1cml0eSAoVExTKQ0KPkRvY3VtZW50IGRhdGU6CTIwMTUtMTItMDgNCj5Hcm91 cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPlBhZ2VzOgkJNg0KPlVSTDogICAgICAgICAgICAN Cj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWF0dHNzb24tdGxz LWVjZGhlLXBzay1hZWFkLTAzLg0KPnR4dA0KPlN0YXR1czogICAgICAgICANCj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tYXR0c3Nvbi10bHMtZWNkaGUtcHNrLWFlYWQv DQo+SHRtbGl6ZWQ6ICAgICAgIA0KPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1t YXR0c3Nvbi10bHMtZWNkaGUtcHNrLWFlYWQtMDMNCj5EaWZmOiAgICAgICAgICAgDQo+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1hdHRzc29uLXRscy1lY2RoZS1wc2st YWVhZC0wMw0KPg0KPkFic3RyYWN0Og0KPiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBzZXZlcmFs IG5ldyBjaXBoZXIgc3VpdGVzIGZvciB0aGUgVHJhbnNwb3J0DQo+ICAgTGF5ZXIgU2VjdXJpdHkg KFRMUykgcHJvdG9jb2wuICBUaGUgY2lwaGVyIHN1aXRlcyBhcmUgYWxsIGJhc2VkIG9uDQo+ICAg dGhlIEVwaGVtZXJhbCBFbGxpcHRpYyBDdXJ2ZSBEaWZmaWUtSGVsbG1hbiB3aXRoIFByZS1TaGFy ZWQgS2V5DQo+ICAgKEVDREhFX1BTSykga2V5IGV4Y2hhbmdlIHRvZ2V0aGVyIHdpdGggdGhlIEF1 dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbg0KPiAgIHdpdGggQXNzb2NpYXRlZCBEYXRhIChBRUFEKSBh bGdvcml0aG1zIEFFUy1HQ00gYW5kIEFFUy1DQ00uICBQU0sNCj4gICBwcm92aWRlcyBsaWdodCBh bmQgZWZmaWNpZW50IGF1dGhlbnRpY2F0aW9uLCBFQ0RIRSBwcm92aWRlcyBwZXJmZWN0DQo+ICAg Zm9yd2FyZCBzZWNyZWN5LCBhbmQgQUVTLUdDTSBhbmQgQUVTLUNDTSBwcm92aWRlcyBlbmNyeXB0 aW9uIGFuZA0KPiAgIGludGVncml0eSBwcm90ZWN0aW9uLg0KPg0KPiAgICAgICAgICAgICAgICAg IA0KPiAgICAgICAgDQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj5zdWJtaXNzaW9uDQo+dW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cj4NCj5UaGUgSUVURiBTZWNyZXRhcmlhdA0KPg0KDQo= From nobody Tue Dec 8 01:32:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9213A1A92EB for ; Tue, 8 Dec 2015 01:32:23 -0800 (PST) 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 GBNzesxAauj5 for ; Tue, 8 Dec 2015 01:32:21 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D8DD1A92EC for ; Tue, 8 Dec 2015 01:32:21 -0800 (PST) Received: by wmww144 with SMTP id w144so173427636wmw.1 for ; Tue, 08 Dec 2015 01:32:20 -0800 (PST) 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 :message-id:references:to; bh=EViUL2uSJ3M0Nkflz3VwFzdWJSxdbgVgwQESckc2Fpk=; b=Qhir55kAzG8XJ0DzXDqxvntI2wCQrrpghIprM7/q7Omk64UOEfJnn475BkyX0Wx9ZV dtnt1RJXiMibN/9FFBTZUeim9/xsWaxnlOONskrYd6kQntCurOFC1y0H+vhc8zuaII/v /bM2uffuyZM7EUUNlz3GUK2TgWEFFDLFzrJm4euDpVknIq8MADVsbiPwewlv5Sno1qtI Fx3mCV3CIYYLEoKzyo4MnZ9rc/9CgmionD3hcg/XthFKknELKJ6fodv48yE6U5Wbg0HT fU9Jm07XTO8HEMdwKyvr4xnaSBmOmwaHdS8pzKiPLHNsYVNoa395+vbvXaFPbWarA0r9 R+fg== X-Received: by 10.194.186.196 with SMTP id fm4mr3028328wjc.152.1449567140050; Tue, 08 Dec 2015 01:32:20 -0800 (PST) Received: from [172.24.251.184] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id s11sm2595305wmb.14.2015.12.08.01.32.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Dec 2015 01:32:19 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_259B588D-B3DA-4865-BBEE-69DC1D5DBDB9" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: Date: Tue, 8 Dec 2015 11:32:13 +0200 Message-Id: <41EB8E23-F4BF-4F4D-9E8E-8BC6D051ABCA@gmail.com> References: To: Software Engineer 979 X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS Record Size Limitation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2015 09:32:23 -0000 --Apple-Mail=_259B588D-B3DA-4865-BBEE-69DC1D5DBDB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 7 Dec 2015, at 11:00 PM, Software Engineer 979 = wrote: >=20 >=20 >> Hello, >>=20 >> I'm currently developing an data transfer application using OpenSSL. = The application is required to securely transfer large amounts of data = over a low latency/high bandwidth network. The data being transferred = lives in a 3rd part application that uses 1 MB buffer to transfer data = to my application. When I hook OpenSSL into my application I notice an = appreciable decline in network throughput. I've traced the issue the = default TLS record size of 16K. The smaller record size causes the 3rd = party application's buffer to be segmented into 4 16K buffers per write = and the resulting overhead considerably slows things down. I've since = modified the version of OpenSSL that I'm using to support an arbitrary = TLS record size allowing OpenSSL to scale up to 1MB or larger TLS record = size. Since this change, my network throughput has dramatically = increased (187% degradation down to 33%).=20 >>=20 >> I subsequently checked the TLS RFC to determine why a 16K record size = was being used, and all could find was the following: >>=20 >> length >> The length (in bytes) of the following TLSCompressed.fragment.=20= >> The length MUST NOT exceed 2^14 + 1024. >>=20 >> The language here is pretty explicit stating that the length must not = exceed 16K (+ some change).Does anyone know the reason for this? Is = there a cryptographic reason why we shouldn't exceed this message size? = Based on my limited experiment, it would appear that a larger record = size would benefit low latency/high bandwidth networks. This is only a guess, but you usually want to fetch the entire record = off the network before you begin decrypting and checking MAC = (unfortunately, it that order), so the intention was to limit that = amount of buffering the receiver is required to do. Perhaps also allow = for more parallel network fetching and decryption. In either case, = these are decisions made almost 20 years ago in SSLv3, and they may or = may not make sense today. Although with all the IoT devices, it might = make even more sense today to reduce buffering requirements. Yoav --Apple-Mail=_259B588D-B3DA-4865-BBEE-69DC1D5DBDB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 7 Dec 2015, at 11:00 PM, Software Engineer 979 <softeng979@gmail.com> wrote:


Hello,

I'm = currently developing an data transfer application using OpenSSL. The = application is required to securely transfer large amounts of data over = a low latency/high bandwidth network. The data being transferred lives = in a 3rd part application that uses 1 MB buffer to transfer data to my = application. When I hook OpenSSL into my application I notice an = appreciable decline in network throughput. I've traced the issue the = default TLS record size of 16K. The smaller record size causes the 3rd = party application's buffer to be segmented into 4 16K buffers per write = and the resulting overhead considerably slows things down. I've since = modified the version of OpenSSL that I'm using to support an arbitrary = TLS record size allowing OpenSSL to scale up to 1MB or larger TLS record = size. Since this change, my network throughput has dramatically = increased (187% degradation down to 33%). 

I subsequently checked the TLS RFC to = determine why a 16K record size was being used, and all could find was = the following:

length
      The length (in bytes) of the following =
TLSCompressed.fragment. 
      The length = MUST NOT exceed 2^14 + 1024.

The language here is pretty explicit = stating that the length must not exceed 16K (+ some change).Does anyone = know the reason for this? Is there a cryptographic reason why we = shouldn't exceed this message size? Based on my limited experiment, it = would appear that a larger record size would benefit low latency/high = bandwidth networks.

This is only a guess, but you usually want to = fetch the entire record off the network before you begin decrypting and = checking MAC (unfortunately, it that order), so the intention was to = limit that amount of buffering the receiver is required to do. Perhaps = also allow for more parallel network fetching and decryption.  In = either case, these are decisions made almost 20 years ago in SSLv3, and = they may or may not make sense today. Although with all the IoT devices, = it might make even more sense today to reduce buffering = requirements.

Yoav


= --Apple-Mail=_259B588D-B3DA-4865-BBEE-69DC1D5DBDB9-- From nobody Tue Dec 8 02:12:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B691A037B for ; Tue, 8 Dec 2015 02:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 R_AXWtCwOWLz for ; Tue, 8 Dec 2015 02:12:35 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978441AC431 for ; Tue, 8 Dec 2015 02:12:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1449569552; x=1481105552; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AsFyUaq9G7vYDr2QLvwYgRK7IRtNs0aOo5PIeJYdkL0=; b=GFBdUV8WxsbNkAR3yu/9FeJ0PGu3jvzvJDtS7usfz0E7OvYfU4NvXzy6 5za4IiU2/PR9XRGTNx1kLjjjtbhtHFN3IjP3oRHJc/EKsNGcQ9+2DIHBp DWPEqSoVYHmcvkH5+j68GYtuoSPiPn2QoaieM6SrRUsVjG59FEoif8LFP RLw32P2/YaM0JVrFrSULjGbKJlBYrq8wibwq7VSe7WOjN6O+Mz0z4QSK/ XQLcwoD5mntZSA9md9JeeM5BwWywvVRKAxiHg2AHLbVo1NmePdJP6vDdu m/fwURM0vkdeRf2RUSOS6MbdQZyCpkPiZ8xsP0hFpyAdD2jLJj0JNPYrx A==; X-IronPort-AV: E=Sophos;i="5.20,399,1444647600"; d="scan'208";a="58166952" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Dec 2015 23:11:54 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Tue, 8 Dec 2015 23:11:54 +1300 From: Peter Gutmann To: Dave Garrett , Software Engineer 979 Thread-Topic: [TLS] TLS Record Size Limitation Thread-Index: AQHRMXCoBFvnL79H4ECX1YuKoin2Tp6/7geAgADwfzU= Date: Tue, 8 Dec 2015 10:11:52 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BA2303@uxcn10-5.UoA.auckland.ac.nz> References: , <201512080349.59635.davemgarrett@gmail.com> In-Reply-To: <201512080349.59635.davemgarrett@gmail.com> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Record Size Limitation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2015 10:12:39 -0000 Dave Garrett writes:=0A= =0A= >A TLS extension to negotiate max length might be viable.=0A= =0A= I think a better starting point would be to look at the implementation that= 's=0A= causing the problem. There's nothing magical about a 16K max segment size= =0A= that causes poor performance, TCP typically has an MSS of 1400-1500 bytes, = one=0A= tenth of the TLS segment size, without there being a 187% loss in throughpu= t=0A= so it looks like the problem is in the implementation, not the protocol. I= =0A= don't see any reason why you couldn't get close to wire speeds, or at least= =0A= min( crypto speed, wire speed ) for TLS for a properly-done implementation.= =0A= =0A= Peter.= From nobody Tue Dec 8 03:21:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628281B29BB for ; Tue, 8 Dec 2015 03:20:59 -0800 (PST) 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_40=-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 LQRy-GDboOuR for ; Tue, 8 Dec 2015 03:20:57 -0800 (PST) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:252::55]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383C41AD1F5 for ; Tue, 8 Dec 2015 03:20:56 -0800 (PST) Received: from 36.54.34.95.customer.cdi.no ([95.34.54.36]:63612 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1a6GKD-0007KQ-S6; Tue, 08 Dec 2015 12:20:53 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Dave Garrett" , "Software Engineer 979" , "Peter Gutmann" References: <201512080349.59635.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4BA2303@uxcn10-5.UoA.auckland.ac.nz> Date: Tue, 08 Dec 2015 12:20:39 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BA2303@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Opera Mail/12.17 (Win32) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Record Size Limitation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2015 11:20:59 -0000 On Tue, 08 Dec 2015 11:11:52 +0100, Peter Gutmann wrote: > Dave Garrett writes: > >> A TLS extension to negotiate max length might be viable. > > I think a better starting point would be to look at the implementation > that's > causing the problem. There's nothing magical about a 16K max segment > size > that causes poor performance, TCP typically has an MSS of 1400-1500 > bytes, one > tenth of the TLS segment size, without there being a 187% loss in > throughput > so it looks like the problem is in the implementation, not the > protocol. I > don't see any reason why you couldn't get close to wire speeds, or at > least > min( crypto speed, wire speed ) for TLS for a properly-done > implementation. > Based on my past experience, a possible reason is that the code does the following: read_event_handler: read data from socket decrypt data handle application data return rather than: read event handler: read data from socket queue data for decryption signal decryption handler return decryption handler: decrypt data handle application data Another factor I have seen influencing speed is the size of the buffer reading from the socket, bigger buffer gives better speed. Within reason, of course; IIRC the benefit of increasing the buffer stops at around 5-10% of the connection speed. A good rule of thumb is that the buffer should be larger than the largest block that you will ever receive over the computer's local connection, provided you read the arriving data when you are notified about the data. I recently saw 10x+ speed increase by changing an application's handling of these two aspects (on Windows). In that case 300KB buffer was sufficient, but I prefer a 1 MB buffer. -- Sincerely, Yngve N. Pettersen From nobody Tue Dec 8 06:54:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E041B2EB5; Tue, 8 Dec 2015 06:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 d0MXPgkVAyZE; Tue, 8 Dec 2015 06:54:21 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 497841B2EB8; Tue, 8 Dec 2015 06:54:21 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 006D5181D1F; Tue, 8 Dec 2015 06:52:18 -0800 (PST) To: rap1011@ksu.edu, rlb@ipv.sx, martin.thomson@gmail.com, alfredo@pironti.eu, agl@google.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151208145219.006D5181D1F@rfc-editor.org> Date: Tue, 8 Dec 2015 06:52:19 -0800 (PST) Archived-At: Cc: tls@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [TLS] [Errata Held for Document Update] RFC7568 (4561) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2015 14:54:23 -0000 The following errata report has been held for document update for RFC7568, "Deprecating Secure Sockets Layer Version 3.0". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7568&eid=4561 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Richard Petrie Date Reported: 2015-12-08 Held by: Stephen Farrell (IESG) Section: 1. Original Text ------------- Since it was released in 1996, the SSLv3 protocol [RFC6101] has been subject to a long series of attacks, both on its key exchange mechanism and on the encryption schemes it supports. Despite being replaced by TLS 1.0 [RFC2246] in 1999, and subsequently TLS 1.1 in 2002 [RFC4346] and 1.2 in 2006 [RFC5246], availability of these replacement versions has not been universal. As a result, many implementations of TLS have permitted the negotiation of SSLv3. The predecessor of SSLv3, SSL version 2, is no longer considered sufficiently secure [RFC6176]. SSLv3 now follows. Corrected Text -------------- Since it was released in 1996, the SSLv3 protocol [RFC6101] has been subject to a long series of attacks, both on its key exchange mechanism and on the encryption schemes it supports. Despite being replaced by TLS 1.0 [RFC2246] in 1999, and subsequently TLS 1.1 in 2006 [RFC4346] and 1.2 in 2008 [RFC5246], availability of these replacement versions has not been universal. As a result, many implementations of TLS have permitted the negotiation of SSLv3. The predecessor of SSLv3, SSL version 2, is no longer considered sufficiently secure [RFC6176]. SSLv3 now follows. Notes ----- TLS 1.1 was first drafted in 2002, but not published until 2006. Similarly, TLS 1.2 was drafted in 2006, but not published until 2008. -------------------------------------- RFC7568 (draft-ietf-tls-sslv3-diediedie-03) -------------------------------------- Title : Deprecating Secure Sockets Layer Version 3.0 Publication Date : June 2015 Author(s) : R. Barnes, M. Thomson, A. Pironti, A. Langley Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Dec 8 15:26:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1731F1ACE08 for ; Tue, 8 Dec 2015 15:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 XrASth_0MRTe for ; Tue, 8 Dec 2015 15:26:21 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2E01ACE11 for ; Tue, 8 Dec 2015 15:26:21 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A64DB4EBBC; Tue, 8 Dec 2015 23:26:20 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 9005C4D631; Tue, 8 Dec 2015 23:26:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1449617180; bh=AHCALjqV7zANpUS2lkeY9uXCDf1Ph41/Epxmt/jNsnM=; l=7179; h=To:References:From:Date:In-Reply-To:From; b=aHPLVjzeIuILN+c67g+Fl8hqxxxm/SRXc0PM/14d8DQKtd55vDEPFd6NPjhWC7cSQ pLVcPQl1PobTsR9r5DsZ+5u0dzHM65xPBs9T3aw50apiN1n2WIPvmyfab/NqCkvOmL +2ie19ugmF0s3zHKRib8o9EJjwJ7EW8CLUJ2YZrc= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 559A42044; Tue, 8 Dec 2015 23:26:20 +0000 (GMT) To: Bill Cox , "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: <5667671C.6020909@akamai.com> Date: Tue, 8 Dec 2015 17:26:20 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030405030403010707070501" Archived-At: Subject: Re: [TLS] Forward secrecy with resumption, and 0-RTT security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2015 23:26:24 -0000 This is a multi-part message in MIME format. --------------030405030403010707070501 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 12/06/2015 08:50 AM, Bill Cox wrote: > I think the current spec does not describe well enough how to > implement secure 0-RTT infrastructure. Instead, it seems to recommend > against using 0-RTT, with a pretty dire warning about the insecurity > of 0-RTT. I think that nearly the entire world will switch to 0-RTT, > regardless of security limitations and warnings. Companies won’t be > able to Perhaps I am living under a rock, but I do not have the sense that "nearly the the entire world will switch to 0-RTT". > resist the improved connection time. IMO, the spec should describe > how to address the security issues with 0-RTT, rather than just > warning about security issues. > > So, here are my dumb thoughts about practical 0-RTT security > infrastructure... > > > One way is to bind resumption to orbits, by having only the orbit that > issues a PSK remember the secret key. Something like this is needed > in any case to provide 0-RTT replay protection. Without at least > orbit-based replay protection, I think it does not make sense to allow > a ClientVerify in a 0-RTT connection. > > > There was a TODO in the last version I read asking what the client > would sign in a 0-RTT ClientVerify. If orbit-based replay protection > is in place using PSKs, then signing anything that identifies what PSK > to use is enough. However, the handshake has to somehow be bound to > the orbit to prevent the signature from being replayed in a MitM > attack. Having a ticket that can only be decrypted using the > orbit-specific ticket decryption key would work. Using a source > address token bound to the orbit would also work. Signing the server > Finish is not required to insure the signature will only be accepted once. > > > There are two parts to a proof-of-possession: uniqueness and > freshness. Uniqueness can be had using orbit-bound PSKs. Insuring > freshness is harder. This could be done by adding timestamps to the > material signed. With this, we would not get a complete proof of > possession, because an attacker can attack the client's clock, unlike > a normal proof of possession. However, if steps are taken to secure > clocks, which is needed for TLS in any case, then we can get what I > think of as "compelling evidence" of possession, which might be good > enough. > > Perhaps I do not fully understand the proposal, but binding to source address and signing timestamps sound an awful lot like things that have been causing headaches for *decades* in the Kerberos community. I would be wary of introducing them into TLS. -Ben --------------030405030403010707070501 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 12/06/2015 08:50 AM, Bill Cox wrote:
I think the current spec does not describe well enough how to implement secure 0-RTT infrastructure.  Instead, it seems to recommend against using 0-RTT, with a pretty dire warning about the insecurity of 0-RTT.  I think that nearly the entire world will switch to 0-RTT, regardless of security limitations and warnings.  Companies won’t be able to

Perhaps I am living under a rock, but I do not have the sense that "nearly the the entire world will switch to 0-RTT".

resist the improved connection time.  IMO, the spec should describe how to address the security issues with 0-RTT, rather than just warning about security issues.

So, here are my dumb thoughts about practical 0-RTT security infrastructure...


One way is to bind resumption to orbits, by having only the orbit that issues a PSK remember the secret key.  Something like this is needed in any case to provide 0-RTT replay protection.  Without at least orbit-based replay protection, I think it does not make sense to allow a ClientVerify in a 0-RTT connection.


There was a TODO in the last version I read asking what the client would sign in a 0-RTT ClientVerify.  If orbit-based replay protection is in place using PSKs, then signing anything that identifies what PSK to use is enough. However, the handshake has to somehow be bound to the orbit to prevent the signature from being replayed in a MitM attack. Having a ticket that can only be decrypted using the orbit-specific ticket decryption key would work. Using a source address token bound to the orbit would also work.  Signing the server Finish is not required to insure the signature will only be accepted once.


There are two parts to a proof-of-possession: uniqueness and freshness.  Uniqueness can be had using orbit-bound PSKs.  Insuring freshness is harder.  This could be done by adding timestamps to the material signed.  With this, we would not get a complete proof of possession, because an attacker can attack the client's clock, unlike a normal proof of possession.  However, if steps are taken to secure clocks, which is needed for TLS in any case, then we can get what I think of as "compelling evidence" of possession, which might be good enough.



Perhaps I do not fully understand the proposal, but binding to source address and signing timestamps sound an awful lot like things that have been causing headaches for *decades* in the Kerberos community.  I would be wary of introducing them into TLS.

-Ben
--------------030405030403010707070501-- From nobody Wed Dec 9 08:14:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD0C1A6F1E for ; Wed, 9 Dec 2015 08:14:53 -0800 (PST) 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 nuejGeswmYkG for ; Wed, 9 Dec 2015 08:14:51 -0800 (PST) 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 703D21A87E1 for ; Wed, 9 Dec 2015 08:13:08 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 8BAF144676; Wed, 9 Dec 2015 17:13:06 +0100 (CET) X-purgate-ID: 152705::1449677586-00002D85-1999A5F4/0/0 X-purgate-size: 1276 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 3B3E140C9F; Wed, 9 Dec 2015 17:13:06 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 314631A3AC; Wed, 9 Dec 2015 17:13:06 +0100 (CET) In-Reply-To: To: Software Engineer 979 Date: Wed, 9 Dec 2015 17:13:06 +0100 (CET) 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: <20151209161306.314631A3AC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS Record Size Limitation 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: Wed, 09 Dec 2015 16:14:53 -0000 Software Engineer 979 wrote: > > I'm currently developing an data transfer application using OpenSSL. The > application is required to securely transfer large amounts of data over a > low latency/high bandwidth network. The data being transferred lives in a > 3rd part application that uses 1 MB buffer to transfer data to my > application. When I hook OpenSSL into my application I notice an > appreciable decline in network throughput. I've traced the issue the > default TLS record size of 16K. The smaller record size causes the 3rd > party application's buffer to be segmented into 4 16K buffers per write and > the resulting overhead considerably slows things down. I've since modified > the version of OpenSSL that I'm using to support an arbitrary TLS record > size allowing OpenSSL to scale up to 1MB or larger TLS record size. Since > this change, my network throughput has dramatically increased (187% > degradation down to 33%). I have strong doubts that the TLS record size is the problem here. But I've seen higher layer design flaws before, which can cause such problems. The OpenSSL membio-interface seems to exhibit quite sub-optimal behaviour, because it moves data around like crazy if you fill it with MBytes of data. -Martin From nobody Wed Dec 9 10:30:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5541A1B2EAE for ; Tue, 8 Dec 2015 06:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 WnAEKLK-q69E for ; Tue, 8 Dec 2015 06:51:53 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9531B2EA4 for ; Tue, 8 Dec 2015 06:51:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7741BBE49; Tue, 8 Dec 2015 14:51:51 +0000 (GMT) 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 qO-kYFzg1lmX; Tue, 8 Dec 2015 14:51:50 +0000 (GMT) Received: from [10.14.104.136] (unknown [136.173.180.16]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F2646BE47; Tue, 8 Dec 2015 14:51:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449586309; bh=k0MVMs4Rdww4P/YRkbjwKH8gl1VZUbTHXsesCY4REmU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=fYsn65SfllKp/uEu2K8l5ryvI9Dcba2qA2W252qQ4yb5Aoow6AI7R5tlbidoZlLbA xFNeMtZSHJIyilSAq2muCz8SaRO1UZsYu92JrvMeuqj3HXwJ92jd8lPtluGXxX5ALQ YBTRoSC4YnikxPk8q0UWYKow2OPk8JeCQcdo49tU= To: Martin Thomson , RFC Errata System References: <20151208034904.5923A180477@rfc-editor.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5666EE84.3030104@cs.tcd.ie> Date: Tue, 8 Dec 2015 14:51:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Wed, 09 Dec 2015 10:30:15 -0800 Cc: Richard Barnes , sean+ietf@sn3rd.com, rap1011@ksu.edu, Adam Langley , Kathleen Moriarty , "tls@ietf.org" , Alfredo Subject: Re: [TLS] [Editorial Errata Reported] RFC7568 (4561) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2015 14:51:55 -0000 On 08/12/15 04:05, Martin Thomson wrote: > On 8 December 2015 at 14:49, RFC Errata System > wrote: >> TLS 1.1 was first drafted in 2002, but not published until 2006. Similarly, TLS 1.2 was drafted in 2006, but not published until 2008. > > > The date on the documents are indeed wrong. > > I recommend holding for document update. Done. (Not that anyone will update that RFC - I doubt we'll want to un-obsolete SSLv3;-) S > From nobody Wed Dec 9 10:30:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2469C1B2DB2 for ; Tue, 8 Dec 2015 05:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 mvq3sJGZ9ZIt for ; Tue, 8 Dec 2015 05:21:35 -0800 (PST) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD2F1ACDC9 for ; Tue, 8 Dec 2015 05:21:35 -0800 (PST) Received: by ioo197 with SMTP id 197so2265110ioo.1 for ; Tue, 08 Dec 2015 05:21:35 -0800 (PST) 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=fwcucVLnvwCcX0FpCUxX1AMw4c2vXpDwAPVuqBcvyco=; b=QQtoW8XusIu8Bxq7Vb/xDZ3dmD9yqHcRp3fMVZcIdRPb++pzMiYK4h+Y7ARrQxnIi2 cRTsocuhrQYlXsgJei0SV4bMFpuTsHNv7MzI42PvfuKl9xnPuNS8JIhcgROImmWVN+wy DV4OzocXW26Rqjj7M+uI63m20g7/EqFkP4qiEL7bRFFDttTWmUHf58wiO2AE0eEv4rRb /dROn3DwvwA6r5TeWFxtVy5ZeUEHmoqZSdPNZYGAsbPlN5NTriXvr6UTfjX2hl03wqUN a6zM5iV/lqvgOg+6vrU0gEKGTX3ABesY8Vbkm5X9fyeCud5Zcu2AdMJM9u84YJ3KXvT2 yUUA== MIME-Version: 1.0 X-Received: by 10.107.162.137 with SMTP id l131mr3471019ioe.49.1449580895047; Tue, 08 Dec 2015 05:21:35 -0800 (PST) Received: by 10.107.146.138 with HTTP; Tue, 8 Dec 2015 05:21:34 -0800 (PST) In-Reply-To: References: <201512080349.59635.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4BA2303@uxcn10-5.UoA.auckland.ac.nz> Date: Tue, 8 Dec 2015 07:21:34 -0600 Message-ID: From: Software Engineer 979 To: "Yngve N. Pettersen" Content-Type: multipart/alternative; boundary=001a1141bbc652952d052662dada Archived-At: X-Mailman-Approved-At: Wed, 09 Dec 2015 10:30:38 -0800 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Record Size Limitation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Dec 2015 13:21:37 -0000 --001a1141bbc652952d052662dada Content-Type: text/plain; charset=UTF-8 Thanks for replies everyone. I also posted the same question the OpenSSL mailing list. One interesting response stated that the size was limited to prevent DOS attacks due to resource exhaustion (in the case that data was being injected). "The peer is required to buffer the entire record before processing it, at at that point the data could be from an untrusted party/attacker. So the limit is for protection against denial-of-service via resource exhaustion." Not sure If I totally buy this as you have the same issue (on a smaller scale) w/16K buffers. Also, you underlying application implementation would have alot to due with as well. On Tue, Dec 8, 2015 at 5:20 AM, Yngve N. Pettersen wrote: > On Tue, 08 Dec 2015 11:11:52 +0100, Peter Gutmann < > pgut001@cs.auckland.ac.nz> wrote: > > Dave Garrett writes: >> >> A TLS extension to negotiate max length might be viable. >>> >> >> I think a better starting point would be to look at the implementation >> that's >> causing the problem. There's nothing magical about a 16K max segment size >> that causes poor performance, TCP typically has an MSS of 1400-1500 >> bytes, one >> tenth of the TLS segment size, without there being a 187% loss in >> throughput >> so it looks like the problem is in the implementation, not the protocol. >> I >> don't see any reason why you couldn't get close to wire speeds, or at >> least >> min( crypto speed, wire speed ) for TLS for a properly-done >> implementation. >> >> > Based on my past experience, a possible reason is that the code does the > following: > > read_event_handler: > read data from socket > decrypt data > handle application data > return > > rather than: > > read event handler: > read data from socket > queue data for decryption > signal decryption handler > return > > decryption handler: > decrypt data > handle application data > > Another factor I have seen influencing speed is the size of the buffer > reading from the socket, bigger buffer gives better speed. Within reason, > of course; IIRC the benefit of increasing the buffer stops at around 5-10% > of the connection speed. A good rule of thumb is that the buffer should be > larger than the largest block that you will ever receive over the > computer's local connection, provided you read the arriving data when you > are notified about the data. > > I recently saw 10x+ speed increase by changing an application's handling > of these two aspects (on Windows). In that case 300KB buffer was > sufficient, but I prefer a 1 MB buffer. > > > > -- > Sincerely, > Yngve N. Pettersen > --001a1141bbc652952d052662dada Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for replies everyone. I also posted the same questi= on the OpenSSL mailing list. One interesting response stated that the size = was limited to prevent DOS attacks due to resource=C2=A0exhaustion (in the case that data was being injected).=

"The peer is required to buffer the entire record be= fore processing it, at at that point the data could be from an untrusted pa= rty/attacker.=C2=A0 So the limit is for protection against denial-of-servic= e via resource exhaustion."

<= span style=3D"font-size:12.8px">Not sure If I totally buy this as you have = the same issue (on a smaller scale) w/16K buffers. Also, you underlying app= lication implementation would have alot to due with as well.

On Tue, Dec 8= , 2015 at 5:20 AM, Yngve N. Pettersen <yngve@spec-work.net> wrote:
On Tue, 08 Dec = 2015 11:11:52 +0100, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:

Dave Garrett <davemgarrett@gmail.com> writes:

A TLS extension to negotiate max length might be viable.

I think a better starting point would be to look at the implementation that= 's
causing the problem.=C2=A0 There's nothing magical about a 16K max segm= ent size
that causes poor performance, TCP typically has an MSS of 1400-1500 bytes, = one
tenth of the TLS segment size, without there being a 187% loss in throughpu= t
so it looks like the problem is in the implementation, not the protocol.=C2= =A0 I
don't see any reason why you couldn't get close to wire speeds, or = at least
min( crypto speed, wire speed ) for TLS for a properly-done implementation.=


Based on my past experience, a possible reason is that the code does the fo= llowing:

read_event_handler:
=C2=A0 read data from socket
=C2=A0 decrypt data
=C2=A0 handle application data
=C2=A0 return

rather than:

read event handler:
=C2=A0 read data from socket
=C2=A0 queue data for decryption
=C2=A0 signal decryption handler
=C2=A0 return

decryption handler:
=C2=A0 decrypt data
=C2=A0 handle application data

Another factor I have seen influencing speed is the size of the buffer read= ing from the socket, bigger buffer gives better speed. Within reason, of co= urse; IIRC the benefit of increasing the buffer stops at around 5-10% of th= e connection speed. A good rule of thumb is that the buffer should be large= r than the largest block that you will ever receive over the computer's= local connection, provided you read the arriving data when you are notifie= d about the data.

I recently saw 10x+ speed increase by changing an application's handlin= g of these two aspects (on Windows). In that case 300KB buffer was sufficie= nt, but I prefer a 1 MB buffer.



--
Sincerely,
Yngve N. Pettersen

--001a1141bbc652952d052662dada-- From nobody Wed Dec 9 10:44:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28E81B2C4A for ; Wed, 9 Dec 2015 10:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 zI8SNKcz1lmU for ; Wed, 9 Dec 2015 10:44:03 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D661ACE9A for ; Wed, 9 Dec 2015 10:44:03 -0800 (PST) Received: by qgcc31 with SMTP id c31so94195239qgc.3 for ; Wed, 09 Dec 2015 10:44:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=I7h6uK1GEvvfOCEuAyEBKjQy35EcvN3qpFsWevivp/o=; b=ZWoHGuBr12i6FN2Q2TnsiUxqxcQieGhU392G5J60VFNZ0iBvNn+anONtKDyDT4v+ga ZJY0FHDVBIgArfsLNS8dcYB3gFNRJfvJFo6ymJti8An0ZsUkWGEQkOkI2nqyQPBCSQIA 9dtrkR/9Mxd+qtzIa4jcewQis8a6OnnZJZH6E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=I7h6uK1GEvvfOCEuAyEBKjQy35EcvN3qpFsWevivp/o=; b=lJ7Y43NuY0o/LfuWrT1iYoVugVitt9dtYGCEWUJsiD4hNwXHyQqyE0yt/N3w8h4jCp eF+YyujZJw7/AGrMFLL7d5qBzRXKHHJ9ue6uGCN6Bcai4GyjLAWhXyZB1nyrhUabpupS IaGltjsvoVTaUFFp+kcVAKhWstBoy33zl+quwK0MQA7KNOhtHzYCl4x4y4UpeY2Y7Z0r GxpooZWB9mOqvAwN8pBy9OcXyk0LJ6zD3RwCZgp/g9nvaa2afUa4jeMmsPKiKFPzIPjL rf7YbKBQRl5YU4FyjMZ8RHzEiUsboAd4dCEGWXkcG2kae9zERV/REBL/dssQSb9qc4qt itJQ== X-Gm-Message-State: ALoCoQmoCzW8/U/f4y6iUkuWaAkZVWBeSx4+jhDLfJAQ8sNKWcULrqe0zYekLL+J5QLuPI/638fZijOnxgW8NbeVvEpj705w/w== X-Received: by 10.140.31.194 with SMTP id f60mr9808785qgf.60.1449686642360; Wed, 09 Dec 2015 10:44:02 -0800 (PST) Received: from [172.16.0.112] (pool-173-73-126-234.washdc.east.verizon.net. [173.73.126.234]) by smtp.gmail.com with ESMTPSA id e62sm4335988qga.47.2015.12.09.10.44.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 09 Dec 2015 10:44:01 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Sean Turner In-Reply-To: <20151205154330.GA25350@LK-Perkele-V2.elisa-laajakaista.fi> Date: Wed, 9 Dec 2015 13:44:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3074F77D-059D-451B-932E-6B9C07197BA5@sn3rd.com> References: <20151205154330.GA25350@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] The progress about theNegotiated FFDHE proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Dec 2015 18:44:04 -0000 On Dec 05, 2015, at 10:43, Ilari Liusvaara = wrote: >=20 > On Sat, Dec 05, 2015 at 11:32:40PM +0800, Xuelei Fan wrote: >> Hi, >>=20 >> Any one know why the negotiated FFDHE draft hang on MISSREF state for = more >> than 180 days? >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ >=20 > Normatively depends on the false-start draft that isn't sent to the > RFC-Editor yet. >=20 > The specification itself is done and all the needed codepoints have > been assigned. I haven=E2=80=99t see any comments on he 01 version so I=E2=80=99m = checking with Bodo to see if he got any off list comments. If not, = we=E2=80=99ll get the WGLC started. spt= From nobody Wed Dec 9 11:08:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A4D1B2D51 for ; Wed, 9 Dec 2015 11:08:37 -0800 (PST) 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, 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 MwHP_PJncKWg for ; Wed, 9 Dec 2015 11:08:35 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47FD1A1B59 for ; Wed, 9 Dec 2015 11:08:35 -0800 (PST) Received: by obciw8 with SMTP id iw8so42571259obc.1 for ; Wed, 09 Dec 2015 11:08:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9/9YDWhEwuhvEe2Q2hfb+CpO3lOqKO4M5kDg8aaqAoE=; b=DTEUSqP8qm7ejro8gGsqjmH29yeKXGn5/4EjrYU0knowRJWMcI4vE9yk6Cg1lfmQpA sLOEfGukax2510UME0qMfZGXDoZQ2Q46g8eyXVlgZbpP96hJOYnnuktvWrUnq6j1zAFd ZpHkRjtCmQzOgncLV4dfBAJMAnCmX0GOvyU7G9pawNdvencW0l0ZwkFxHEfv6RlidK+S 0jleqvr/eQWBrOvHbByvgsodF/jfTdpugijgWsrn1yt/7zQH7BRT92LMkFc1oCFYV0pe kCP80WXE6P4Fit9ZotiLArZFwwMeSxlcxu1TO5F2qD0XsS4wzC2nCzlyja+fab9BWjxM b+7g== 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=9/9YDWhEwuhvEe2Q2hfb+CpO3lOqKO4M5kDg8aaqAoE=; b=XgAQQQuVh8GNR7RfVMddTbhrvQKu/ec8Obj2ggk7YNu5MB9HChgGHws2gtDSSEBUuD pq4KEu4M7gnhsKHTADc63g9/81xJ1D9ujzodOMsIIu0WU7NQwCsSeO7AypxS3+aqVLKu EiXN4h5VO5B5Bx36vud+riAazWGM02esgtvLra4FcHF+pmQLJzYBAW095bc05LF4GOlM HLL2tNPGzaX4ThmRu0dhyRjw3Jg2D7++SlBIrYtsL49lczpbpdkmoZSjbNITHetI/0p7 cJ9L/uE6hD0ru/QBaLuXVCnp2QuhOZekJ5klJa1A/rHVE8cHEB2Tqzgz7cs9tNkF3zDT WDWw== X-Gm-Message-State: ALoCoQldVCJwxqJRqmtCac2+XYS5uu0UjQr4K0y5MG0BfXce3ZbvksZDWXzLCTojBoQXQsmy0RdjHsqllOIUpETwG1OfAJ75Dg== MIME-Version: 1.0 X-Received: by 10.182.241.3 with SMTP id we3mr5981111obc.9.1449688115032; Wed, 09 Dec 2015 11:08:35 -0800 (PST) Received: by 10.76.109.78 with HTTP; Wed, 9 Dec 2015 11:08:34 -0800 (PST) In-Reply-To: <3074F77D-059D-451B-932E-6B9C07197BA5@sn3rd.com> References: <20151205154330.GA25350@LK-Perkele-V2.elisa-laajakaista.fi> <3074F77D-059D-451B-932E-6B9C07197BA5@sn3rd.com> Date: Wed, 9 Dec 2015 09:08:34 -1000 Message-ID: From: Brian Smith To: Sean Turner Content-Type: multipart/alternative; boundary=001a11c3608c21d3e705267bd1f2 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] The progress about theNegotiated FFDHE proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Dec 2015 19:08:37 -0000 --001a11c3608c21d3e705267bd1f2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 9, 2015 at 8:44 AM, Sean Turner wrote: > On Dec 05, 2015, at 10:43, Ilari Liusvaara > wrote: > > > > On Sat, Dec 05, 2015 at 11:32:40PM +0800, Xuelei Fan wrote: > >> Hi, > >> > >> Any one know why the negotiated FFDHE draft hang on MISSREF state for > more > >> than 180 days? > >> > >> http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ > > > > Normatively depends on the false-start draft that isn't sent to the > > RFC-Editor yet. > > > > The specification itself is done and all the needed codepoints have > > been assigned. > > I haven=E2=80=99t see any comments on he 01 version so I=E2=80=99m checki= ng with Bodo to > see if he got any off list comments. If not, we=E2=80=99ll get the WGLC = started. > The FF-DHE draft should be reset so that it specifies new cipher suite IDs for TLS_DHE_* cipher suites with the same semantics as the current TLS_DHE_* cipher suites, but with the requirement that the FF-DHE extension is present (for TLS 1.2 and earlier versions). As predicted long ago, the current design of this extension doesn't make sense because it doesn't allow for a client to require a strong DHE key and at the same time maintain compatibility with sites that use weak DHE keys when DHE cipher suites are offered but which would use a strong non-DHE cipher suite if DHE cipher suites are not offered. Additionally, because of the Microsoft SChannel AES-GCM bug from last year, it is very difficult to deploy a client that uses TLS-DHE-AES-GCM or TLS-AES-GCM cipher suites. This is more motivation for the proposal in the previous paragraph. If the current proposal goes ahead unmodified, I suspect most implementers will be forced to ignore it and simply turn of TLS_DHE cipher suites completely. That's what Apple Safari did, what Google Chrome appears to be doing, and also what Firefox partially did. If the goal is really to deprecate TLS_DHE cipher suites completely, then the wording of the draft should be made much simpler and more direct to that effect. Cheers, Brian -- https://briansmith.org/ --001a11c3608c21d3e705267bd1f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Dec 9, 2015 at 8:44 AM, Sean Turner <sean@sn3rd.com> wrote:=
On Dec 05, 2015, at 10:= 43, Ilari Liusvaara <ilarili= usvaara@welho.com> wrote:
>
> On Sat, Dec 05, 2015 at 11:32:40PM +0800, Xuelei Fan wrote:
>> Hi,
>>
>> Any one know why the negotiated FFDHE draft hang on MISSREF state = for more
>> than 180 days?
>>
>>=C2=A0 =C2=A0 http://datatr= acker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/
>
> Normatively depends on the false-start draft that isn't sent to th= e
> RFC-Editor yet.
>
> The specification itself is done and all the needed codepoints have > been assigned.

I haven=E2=80=99t see any comments on he 01 version so I=E2=80=99m c= hecking with Bodo to see if he got any off list comments.=C2=A0 If not, we= =E2=80=99ll get the WGLC started.

The F= F-DHE draft should be reset so that it specifies new cipher suite IDs for T= LS_DHE_* cipher suites with the same semantics as the current TLS_DHE_* cip= her suites, but with the requirement that the FF-DHE extension is present (= for TLS 1.2 and earlier versions). As predicted long ago, the current desig= n of this extension doesn't make sense because it doesn't allow for= a client to require a strong DHE key and at the same time maintain compati= bility with sites that use weak DHE keys when DHE cipher suites are offered= but which would use a strong non-DHE cipher suite if DHE cipher suites are= not offered.

Additionally, because of the Microso= ft SChannel AES-GCM bug from last year, it is very difficult to deploy a cl= ient that uses TLS-DHE-AES-GCM or TLS-AES-GCM cipher suites. This is more m= otivation for the proposal in the previous paragraph.

<= div>If the current proposal goes ahead unmodified, I suspect most implement= ers will be forced to ignore it and simply turn of TLS_DHE cipher suites co= mpletely. That's what Apple Safari did, what Google Chrome appears to b= e doing, and also what Firefox partially did.

If t= he goal is really to deprecate TLS_DHE cipher suites completely, then the w= ording of the draft should be made much simpler and more direct to that eff= ect.

Cheers,
Brian
--
https://briansmith.org/
--001a11c3608c21d3e705267bd1f2-- From nobody Wed Dec 9 17:02:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1102D1A6F92 for ; Wed, 9 Dec 2015 17:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 SXPWWCxyQhFH for ; Wed, 9 Dec 2015 17:02:51 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 14FEE1A6F8F for ; Wed, 9 Dec 2015 17:02:50 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2DB17433439 for ; Thu, 10 Dec 2015 01:02:50 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 17B8A433434 for ; Thu, 10 Dec 2015 01:02:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1449709370; bh=hGTbWgPPYoFC/PH8/qb0yOfvzoTrvdmdwEIWZmVQhEs=; l=2732; h=From:To:Date:From; b=nZD42mZqjEGAuZhW11K4tWeFtdgofMKlhp8yWppk4xq4Qh7Zf9o41F8vkWBTAduJH rXerNAPGgFnkPESNfq4rxuoqrBE6sPJB/OGM8Ph1adEbeu0i79e7ANFGMjyhtsi42B ahRsScL2i1bCu6QKZdBFmHmSMRqB2vypaeuKN/vI= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 1041C2042 for ; Thu, 10 Dec 2015 01:02:50 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 9 Dec 2015 20:02:49 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Wed, 9 Dec 2015 20:02:49 -0500 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: chacha/poly interop? Thread-Index: AdEy3kqGvrJfP1jPT6ybBgSch0agHw== Date: Thu, 10 Dec 2015 01:02:49 +0000 Message-ID: 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: [172.19.32.228] Content-Type: multipart/alternative; boundary="_000_ffd74054d64047cd9dfebc6e9fd6bc19usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [TLS] chacha/poly interop? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2015 01:02:53 -0000 --_000_ffd74054d64047cd9dfebc6e9fd6bc19usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OpenSSL just landed our chacha/poly implementation into master. We pass th= e RFC test vectors, looking for other implementations to test against. Tha= nks. -- Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz --_000_ffd74054d64047cd9dfebc6e9fd6bc19usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OpenSSL just landed our chacha/poly implementation i= nto master.  We pass the RFC test vectors, looking for other implement= ations to test against.  Thanks.

 

-- 

Senior Architect, Akamai Technologies

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_ffd74054d64047cd9dfebc6e9fd6bc19usma1exdag1mb1msgcorpak_-- From nobody Wed Dec 9 17:22:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9991F1A870E for ; Wed, 9 Dec 2015 17:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, T_RP_MATCHES_RCVD=-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 7mMxjhOB3Thb for ; Wed, 9 Dec 2015 17:22:24 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA97F1A86F3 for ; Wed, 9 Dec 2015 17:22:24 -0800 (PST) Received: by iofh3 with SMTP id h3so79686497iof.3 for ; Wed, 09 Dec 2015 17:22:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=M/PwA5BiG8IIP5F6fR4Fyb9Wt+4UNAzyMuCVAiOzlaY=; b=emInBknqj0nZDw3bfIiOn+tQzWxZQW+YtfKq5K/Pl2eJg9SI2FzDcyM8gDOVCG777i j0oUvJKK6+pA0ifOwbPWiA/C8DzjBlQvAv5sC4U1ZBNCYgg1F7J6AkTfTO7XzYDZNaJ5 rDkgtDdHHj0GMEf9Jx0TSY8qrCjXn7YvZR0Ow= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=M/PwA5BiG8IIP5F6fR4Fyb9Wt+4UNAzyMuCVAiOzlaY=; b=cxnpTh7db7VtdiFrL4NYwjRA7o8pEjOkI+Fq1HLdp9Z23RwmfK4uQP6RmC/6s1UH7R vhZf+jdo136wkPpiFgsBmzUmLEtH8K00ZJfPpDKlUe5Y+LLOyUvmEiHGvIh6zDOQy2j0 MuTaMqc3f6fYOouR14o0bIiFsdJ3aPF0kS64rq71mYI9RxoPuUHzMuV1pIKg0WwzZaty dDgJvLTH76VfMTjtAgpAIaCswsjIrP+cgKtqtbkD5J1Rbwxe4OFaacW8fPHN8UEfKsA6 EYdGOeHwMuNgI3R0anjt014SgxNQPdA7xRksLH/qGR8CK5OrTN1flfuwWKjITgQbGFzQ cD/g== X-Gm-Message-State: ALoCoQm+sckMKelxZGZIrYj+jX7Zh6uLwF/OYl1itzisgnhw0nh3HAfDeIiuQvSiFPxepuhizIWMLVFVFATujxwE/yj2LzomFxRPAQidIfOrRQQD5LpIb1I= X-Received: by 10.107.44.210 with SMTP id s201mr10614983ios.62.1449710544022; Wed, 09 Dec 2015 17:22:24 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Thu, 10 Dec 2015 01:22:13 +0000 Message-ID: To: "Salz, Rich" , "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113978f202881f0526810aed Archived-At: Subject: Re: [TLS] chacha/poly interop? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2015 01:22:26 -0000 --001a113978f202881f0526810aed Content-Type: text/plain; charset=UTF-8 BoringSSL has an implementation of the AEAD itself you could test against. It's the EVP_AEAD named EVP_aead_chacha20_poly1305_rfc7539 (to be renamed to EVP_aead_chacha20_poly1305 later). On Wed, Dec 9, 2015 at 8:02 PM Salz, Rich wrote: > OpenSSL just landed our chacha/poly implementation into master. We pass > the RFC test vectors, looking for other implementations to test against. > Thanks. > > > > -- > > Senior Architect, Akamai Technologies > > IM: richsalz@jabber.at Twitter: RichSalz > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113978f202881f0526810aed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
BoringSSL has an implementation of the AEAD itself you cou= ld test against. It's the EVP_AEAD named EVP_aead_chacha20_poly1305_rfc= 7539 (to be renamed to EVP_aead_chacha20_poly1305 later).

On Wed, Dec 9, 2015 at 8:02 PM Salz, Ric= h <rsalz@akamai.co= m> wrote:

OpenSSL just landed our chacha/poly implementation i= nto master.=C2=A0 We pass the RFC test vectors, looking for other implement= ations to test against.=C2=A0 Thanks.

=C2=A0

--=C2=A0

Senior Architect, Akamai Technologies<= /p>

IM: richsalz@jabber.at Twitter: RichSalz

=C2=A0

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a113978f202881f0526810aed-- From nobody Thu Dec 10 06:47:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1BE1B32B0 for ; Thu, 10 Dec 2015 06:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 AYYLmokeThGC for ; Thu, 10 Dec 2015 06:47:29 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E1B1B32B1 for ; Thu, 10 Dec 2015 06:47:29 -0800 (PST) Received: by qgea14 with SMTP id a14so145976759qge.0 for ; Thu, 10 Dec 2015 06:47:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=tBPY/tD9yPS7tN713lhRHkNZBso8jsbVuUjIjmVYni8=; b=mHXSSe2832Qjl2mxVM5CI63GzbWigZZWDMRruWuc9UmgUK05jdp9KEKVs3+b2z1Kv4 qem5FoyhXm/Z6l3f07KVhLZKdHenGdm4ihltt7Sc0Gs4Ls7wP55Zjol+XzI/Zy33hyWb 2kkzGdtCsnfY93h4+4oVVXT/Pv9bsl2NK/gqE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=tBPY/tD9yPS7tN713lhRHkNZBso8jsbVuUjIjmVYni8=; b=WdUuEDRMD5nXEHo8iHc1DDHMfXBky5CS3AOJcDXuQ+e6Z/ZeBFy/KQvTTHMJy5Kc1H gm4zkDDg+Z4jMV6qai3B9L2FvfvnH0oPL1bD51kau2pFDFb4SddYG/XN+ekmbGi921Tb nj/FqapUr0ZLe5/GEUeHofZkVHf2hTjvQGfE7tdDCkILkW0180RHs/+9tJ31GHz8xWNw KU0P1sJW37B0wb+UAr831MAokdkcYISpDXkFX9gHyCV4jCg1Gh5hL9IOS3FBkPRemjbg 6uPiIKCzK56e6jwYP73MV64vYJeBYvCtSeRqQsCIQrtbmTT1eDYJcrCsiqS5MmpMYN71 xLJw== X-Gm-Message-State: ALoCoQnR4txr0c30sFSM/y2pwTRcUACzixNmVvACPL7OW+kpwROQ920g6aUtvqhYS7tPqJxZY0QOU4T07+Rt0/gIwk69ZIfBIA== X-Received: by 10.55.198.81 with SMTP id b78mr15523180qkj.102.1449758847901; Thu, 10 Dec 2015 06:47:27 -0800 (PST) Received: from [172.16.0.112] (pool-173-73-126-234.washdc.east.verizon.net. [173.73.126.234]) by smtp.gmail.com with ESMTPSA id z65sm6090279qhc.27.2015.12.10.06.47.26 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Dec 2015 06:47:26 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Sean Turner In-Reply-To: Date: Thu, 10 Dec 2015 09:47:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3AE96EBB-4580-4659-991E-DC7048098408@sn3rd.com> References: <385E6AFF-52C3-4E40-A69F-178602A449A7@sn3rd.com> <56538760.4000909@cs.tcd.ie> To: "" X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [TLS] Early code point assignments for 25519/448 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, 10 Dec 2015 14:47:31 -0000 All, The CFRG is currently conducting a quaker poll about filling in two = missing functions for the 448 so we=E2=80=99re going follow the = suggestion from ekr/ilari to wait until they=E2=80=99re done. If you = care to chime in on the poll it can be found here: = https://mailarchive.ietf.org/arch/msg/cfrg/XxJ9PwL6GjEq6necM83Hr8JoIw0 spt > On Nov 23, 2015, at 17:01, Eric Rescorla wrote: >=20 > if it's only a few weeks, let's just do all the signature code points > then. >=20 > -Ekr >=20 >=20 > On Mon, Nov 23, 2015 at 1:38 PM, Stephen Farrell = wrote: >=20 > Hiya, >=20 > On 23/11/15 14:21, Sean Turner wrote: > > All, > > > > We=E2=80=99ve received an early code point assignment for the = following 4 >=20 > Is the word "request" missing above? Either that or I'm forgetting > more than I suspected:-) >=20 > > (four) elliptic curve points that will go in the "Supported Groups" > > Registry: > > > > // ECDH functions. ecdh_x25519 ecdh_x448 > > > > // Signature curves. eddsa_ed25519 eddsa_ed448 >=20 > I think 3 of the above are clearly fine now. >=20 > I'd suggest holding off on eddsa_ed448 for a while until CFRG > are done, but maybe establishing now that there is consensus in > the WG to allocate that as soon as CFRG are done (where "done" > means folks can implement and interop, not that the RFCs are > issued). >=20 > AFAIK the state of play within CFRG on that is that the chairs > plan to do a few polls for the couple of remaining issues in > a few weeks, so we're not talking about a major delay and to > be fair, CFRG recently have delivered more or less when they > said they would. >=20 > My reason to suggest this is just in case CFRG discover some > last minute stuff. While burning a code-point for that wouldn't > be a problem, we'd be better off without the confusion. >=20 > But if (the chairs tell me) there's clear consensus for some > other action here, I'll consider myself in the rough and go with > that. >=20 > Cheers, > S. >=20 >=20 > > > > These points will be included in the following 2 (two) drafts: > > draft-ietf-tls-tls13 draft-ietf-tls-rfc4492bis. > > > > Early code points are permitted in the =E2=80=9CSupported Groups=E2=80= =9D registry > > and the chairs (that=E2=80=99s us) need to determine whether there = is support > > for these assignments. Some input has already been received and > > those people do not need to respond again to this call, but we=E2=80=99= d like > > to hear from others whether they support early code point assignment > > for these curves. If you do not please state why. We=E2=80=99re = looking for > > input by November 30th. > > > > J&S _______________________________________________ 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 >=20 From nobody Thu Dec 10 08:02:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102FF1A0235 for ; Thu, 10 Dec 2015 08:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-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 KgH-HVXlIAZ5 for ; Thu, 10 Dec 2015 08:02:48 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8021C1A0211 for ; Thu, 10 Dec 2015 08:02:48 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 2F3D2C1A1670; Thu, 10 Dec 2015 16:02:48 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-16.ams2.redhat.com [10.36.112.16]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBAG2hxo014271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2015 11:02:47 -0500 From: Hubert Kario To: tls@ietf.org Date: Thu, 10 Dec 2015 17:02:42 +0100 Message-ID: <2237279.MTOY4af0Ff@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.6-201.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3442332.GJ6sgHhYIh"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Subject: Re: [TLS] chacha/poly interop? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2015 16:02:53 -0000 --nextPart3442332.GJ6sgHhYIh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 10 December 2015 01:02:49 Salz, Rich wrote: > OpenSSL just landed our chacha/poly implementation into master. We > pass the RFC test vectors, looking for other implementations to test > against. Thanks. I have implementation in pure Python here: https://github.com/tomato42/tlslite-ng/blob/master/tlslite/utils/chacha= 20_poly1305.py There's also support for the obsolete draft-00 of the TLS ciphersuites.= =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart3442332.GJ6sgHhYIh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJWaaIiAAoJEJKo0bgB0vX1l+IQAKDmYoO6MQnkcgX7RSrQte/4 L+F60KlILsJ2CfsNfRdIvxDiuTsEgKM9YhXfErKKeb15BekPPmDsLzp8wGXrDPcB QsVPt2z+bBRKRmyPXiZAsjmF3cRI7l9EfeiljxFBoSNH4XVcyKpwZvM+gF1QguBA LTFEbUq98vvscSfCMaCzdp/J+3dSfA1GzacDLBPZ8uv/1lrBfs9J1SFS6wyw7JxE PLj95DcjDWOMr71NuGaURFBfX9ai8Iku5p4ezlljAtHrrPZ+DMy/Cjj53Zu7xale 4sZIpkjFOpWAqFEujycgANTmHgsZ9mPhTgwQ7S6/baFsjklN/wqg3v21Q/XiKIDv X7Fz5yWFqp6CLl7SeXzctsXIgZOepxclYUXf8OYyHW69oCmqxVxvTn4BAe8sNWnf sbG/OfFsDUJVmEHMSkv485R2kjTxICgFI+Z9r2sE/xG2KvJsITy9C8wUfeHk0lb2 TnYhQimwk4ykXXEoHFpAk4Hedz4PUwTj40HbaSGlIVtqud37ppuhreNdUuelbT/u OKe8o86pCmbAp/gS9UCSHWYasLS8enLlMQ23E3pLp/UH5GNweZs9jLHQwlYDLgS3 2m2+YbHn73oSa2VeNDmXxXUUZUrcX2v2n3aPveSSBu/RMGx1398yO0qoxfTK6Nct hrm54g3+2kejNkcWbOmc =UJPp -----END PGP SIGNATURE----- --nextPart3442332.GJ6sgHhYIh-- From nobody Thu Dec 10 09:40:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277A21A905C for ; Thu, 10 Dec 2015 09:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, 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 GHW5j6_rYKmI for ; Thu, 10 Dec 2015 09:40:24 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143221A9054 for ; Thu, 10 Dec 2015 09:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1129; q=dns/txt; s=iport; t=1449769224; x=1450978824; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=D5zz5BasJDVViRq/7jx5hK7Yv2Z+KMLZGG93H1lmsuM=; b=ReIz/TFnNideInXqAUK660UGP/Ef3a9g4Z6xmL0Wn0GHV+2iu6veeHer QC+oIpMJliWWBrFpl0hdNbJt6VqB3h6XunEcxXH5MWOcPeTSVvvNo60kR kX5YoS7S+JL/pxcdM2G/uDwXuU2ZOMcpuNzy6a0DRkLAkKrC/NlRiHMEu o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVBQCNuGlW/5JdJa1egzrAbIdJOxEBA?= =?us-ascii?q?QEBAQEBgQqEXhVANgIFFgsCCwMCAQIBWAgBAYgrnliPcJIOLYEBj3mCUIFJBY4?= =?us-ascii?q?niEiNQ4kkk2U3LIQiIIYOAQEB?= X-IronPort-AV: E=Sophos;i="5.20,409,1444694400"; d="scan'208";a="52396637" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Dec 2015 17:40:23 +0000 Received: from [10.82.161.102] ([10.82.161.102]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tBAHeMt4014982 for ; Thu, 10 Dec 2015 17:40:23 GMT To: tls@ietf.org From: John Foley Message-ID: <5669B920.9080001@cisco.com> Date: Thu, 10 Dec 2015 12:40:48 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] EncryptedExtensions message in [draft-ietf-tls-tls13-10] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2015 17:40:25 -0000 While reviewing the latest TLS 1.3 draft (revision 10), the description in section 6.3.3 uses the following wording: When this message will be sent: If this message is sent, it MUST be sent immediately after the ServerHello message. This is the first message that is encrypted under keys derived from ES. The use of the word "if" implies this is an optional message. However, Figure 1 in section 6.2 implies the EncryptedExtensions message is not optional since it's not footnoted with an asterisk. The asterisk footnote is described as: Indicates optional or situation-dependent messages that are not always sent. Can anyone comment on whether the EncryptedExtensions message is optional? If it is, should Figure 1 be updated to reflect this? Or, should the the text in section 6.3.3 be updated to indicated this message is required? This is an important detail for implementors, since the client-side state machine will need to know whether to expect the EncryptedExtensions message after the ServerHello, or to expect another one of the subsequent messages. From nobody Thu Dec 10 09:56:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76EC61A90F4 for ; Thu, 10 Dec 2015 09:56:31 -0800 (PST) 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, HTML_MESSAGE=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 6V-47bclvGHD for ; Thu, 10 Dec 2015 09:56:30 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3361A8A87 for ; Thu, 10 Dec 2015 09:56:30 -0800 (PST) Received: by vkha189 with SMTP id a189so93821239vkh.2 for ; Thu, 10 Dec 2015 09:56:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ch1pz17JdmG64CgTYbC7UT7Cfr875o4L/H3VR+lKbdo=; b=cT+mBDiuJvoUOkd7R1FPx+XhYd3/hq3mC1FdqVl437jIQudcGL96K9QN23oLzgNUE1 e/aKXZNNkv3pp4a2MG8qbDGzvXHNQhLCNBjpoR3tAI3keGBO2+BeVswu2HZ4J9N+aBWJ +Aw/yMuylP9lttzJkvWiZ0eXkN6iHgGkfT8sK8Vju/kUI00SbtJjILOjn4ckgAyWYjV6 ceglBZdeYJhoZRb6xs+UMlvx8UDftwFRo93kugEdTDzeGvb0dfidCcoq+mtq9sDMc5xW djCLla4gV8DwXcqjFr+2wfGyq4KmfGJ2LCbzeG7GBCe8QPvsQPytSXB9DzKeqC6S1KD7 hdnA== 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=Ch1pz17JdmG64CgTYbC7UT7Cfr875o4L/H3VR+lKbdo=; b=a/cUDYiifqVPGWfjzNZxP4EVSTvmfi2MoD4GWX67j1KLwKfIXb2cvmULJaD8S33+vm dz+Ye/3ku4d76UHRPICUkKAPWsNzxed+aoe/5YsCrtEVwWC9HQdpmkEwA64YFCyPkBOT MGStJmYLB5iVkSPiY/aSkcnAc8OeG4helya0SnsPLJ3a+2zb7hzGzM6qvFr6+BCkLtaV DC+49jC7+fcNGMx/d+HhHhg3NI0ot3PlyRSXJ//IQcVEgwO5bxsgXHL3bLevqQ6yRuNJ MJY6bg2huelbYgNcy0FJbPEQF5MuK+kqQipO2Hn9rblCS2w7gV2/UcCQqDp+7yCe0YqW Pfdw== X-Gm-Message-State: ALoCoQm9mayhyKkCpdgIwG15BPniftCG8oTTBEtsfTXdVJWjCcxEOAeF2UoOWE8dH44yDaIYi2aQJdfLBLfJEAtGhUSW9yLy8A== X-Received: by 10.13.236.10 with SMTP id v10mr5735826ywe.231.1449770189087; Thu, 10 Dec 2015 09:56:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Thu, 10 Dec 2015 09:55:49 -0800 (PST) In-Reply-To: <5669B920.9080001@cisco.com> References: <5669B920.9080001@cisco.com> From: Eric Rescorla Date: Thu, 10 Dec 2015 12:55:49 -0500 Message-ID: To: John Foley Content-Type: multipart/alternative; boundary=94eb2c0889dc20972905268eed8c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] EncryptedExtensions message in [draft-ietf-tls-tls13-10] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2015 17:56:31 -0000 --94eb2c0889dc20972905268eed8c Content-Type: text/plain; charset=UTF-8 On Thu, Dec 10, 2015 at 12:40 PM, John Foley wrote: > While reviewing the latest TLS 1.3 draft (revision 10), the description in > section 6.3.3 uses the following wording: > > When this message will be sent: > > If this message is sent, it MUST be sent immediately after the > ServerHello message. This is the first message that is encrypted > under keys derived from ES. > > > The use of the word "if" implies this is an optional message. However, > Figure 1 in section 6.2 implies the EncryptedExtensions message is not > optional since it's not footnoted with an asterisk. The asterisk footnote > is described as: > > Indicates optional or situation-dependent messages that are not always > sent. > > > Can anyone comment on whether the EncryptedExtensions message is > optional? If it is, should Figure 1 be updated to reflect this? Or, should > the the text in section 6.3.3 be updated to indicated this message is > required? > > This is an important detail for implementors, since the client-side state > machine will need to know whether to expect the EncryptedExtensions message > after the ServerHello, or to expect another one of the subsequent messages. > Yes, I agree. It is mandatory. Pilot error on my part. -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0889dc20972905268eed8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 10, 2015 at 12:40 PM, John Foley <foleyj@cisco.com><= /span> wrote:
While reviewing the latest = TLS 1.3 draft (revision 10), the description in section 6.3.3 uses the foll= owing wording:

When this message will be sent:

=C2=A0 =C2=A0 =C2=A0 If this message is sent, it MUST be sent immediately a= fter the
=C2=A0 =C2=A0 =C2=A0 ServerHello message.=C2=A0 This is the first message t= hat is encrypted
=C2=A0 =C2=A0 =C2=A0 under keys derived from ES.


The use of the word "if" implies this is an optional message. How= ever, Figure 1 in section 6.2 implies the EncryptedExtensions message is no= t optional since it's not footnoted with an asterisk. The asterisk foot= note is described as:

Indicates optional or situation-dependent messages that are not always sent= .


Can anyone comment on whether the EncryptedExtensions message is optional?= =C2=A0 If it is, should Figure 1 be updated to reflect this? Or, should the= the text in section 6.3.3 be updated to indicated this message is required= ?

This is an important detail for implementors, since the client-side state m= achine will need to know whether to expect the EncryptedExtensions message = after the ServerHello, or to expect another one of the subsequent messages.=

Yes, I agree.

It is mandatory. Pilot error on my part.

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

--94eb2c0889dc20972905268eed8c-- From nobody Thu Dec 10 09:57:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123B51A9125 for ; Thu, 10 Dec 2015 09:57:04 -0800 (PST) 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, HTML_MESSAGE=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 AEwuDb017t83 for ; Thu, 10 Dec 2015 09:57:02 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C151A9111 for ; Thu, 10 Dec 2015 09:57:02 -0800 (PST) Received: by vkbs1 with SMTP id s1so94006569vkb.1 for ; Thu, 10 Dec 2015 09:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=l571kTihXZhjYEf2aJzFAts2+YSm1cpEFr2lEmfd6Z4=; b=zOhhNHASDQRXISjEdlKaqdmI+1gZd/Ies/dh2suWcxOq0nF9jYjt/NuQsBTO6jKK+t R84CcweEq4ii2c0Be6LiAQktNixS6Kv2b8ogRCOyVHXL5ugb58fGlmvyJPbfof5HQHei 7uvF3M72VkSpGZ5uHNTvx4wgC26KjoIPYyxOvoCqeiSJrSjncPmEsphzXnnr+L0jJnx1 N9869oludIoRe4uanysntoLyeir9qagLla0L8Nf+3RvFzchVfFagtxAW8oOkGQeZu07J 61ngmdvOG4Q5en/Dn6uHpiAxro91h7tXJ7FGYfiVNg/2TdPOWiV4pmZ+Gt+sxMlb3oK9 KLDA== 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=l571kTihXZhjYEf2aJzFAts2+YSm1cpEFr2lEmfd6Z4=; b=YKhZyoc7yAgjBRVOPsqrSDF9z1P+E5g7u/mRBpDoaYQSTzM+OqCrHWD1MLwJRywF5w ovG65RPoLCmvPPzpUn3bYojEHjilHSQscpVeeuWJNfLPl/GsDq4A5bPcLRzMUVt61xWi AroeugMvIn+YUW73t6l+sCSsAEQ4hdqxGBIIHSDxQuKcH7zq0hGzhRk3bfyFI1OU4qq9 CeWlxxTv5mJ73Q8ugngPnSQqauYc5Hq2fvEuylMcHJjSnGywqU2KTGQXb9ySYh4g5uoM AurUL12lz6SBI/we3jfxH6RKkWGrhe5rfJpC0xXTjNJrc4dGSfBmz6Rv3g5RLqcCNuzR 88SA== X-Gm-Message-State: ALoCoQmS6bspwDPIQ6GSY6Fb1+VWW4JixOpPTk29JssmYtUbeqb+sNJxqXI0eVqZUpbq5AQ/q1D0SphU3Wiow8zv6T95B9e7pA== X-Received: by 10.13.212.211 with SMTP id w202mr5778752ywd.192.1449770221732; Thu, 10 Dec 2015 09:57:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Thu, 10 Dec 2015 09:56:22 -0800 (PST) In-Reply-To: References: <5669B920.9080001@cisco.com> From: Eric Rescorla Date: Thu, 10 Dec 2015 12:56:22 -0500 Message-ID: To: John Foley Content-Type: multipart/alternative; boundary=001a114fbe9812b61305268eef4b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] EncryptedExtensions message in [draft-ietf-tls-tls13-10] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2015 17:57:04 -0000 --001a114fbe9812b61305268eef4b Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/issues/362 so this doesn't get lost. On Thu, Dec 10, 2015 at 12:55 PM, Eric Rescorla wrote: > > > On Thu, Dec 10, 2015 at 12:40 PM, John Foley wrote: > >> While reviewing the latest TLS 1.3 draft (revision 10), the description >> in section 6.3.3 uses the following wording: >> >> When this message will be sent: >> >> If this message is sent, it MUST be sent immediately after the >> ServerHello message. This is the first message that is encrypted >> under keys derived from ES. >> >> >> The use of the word "if" implies this is an optional message. However, >> Figure 1 in section 6.2 implies the EncryptedExtensions message is not >> optional since it's not footnoted with an asterisk. The asterisk footnote >> is described as: >> >> Indicates optional or situation-dependent messages that are not always >> sent. >> >> >> Can anyone comment on whether the EncryptedExtensions message is >> optional? If it is, should Figure 1 be updated to reflect this? Or, should >> the the text in section 6.3.3 be updated to indicated this message is >> required? >> >> This is an important detail for implementors, since the client-side state >> machine will need to know whether to expect the EncryptedExtensions message >> after the ServerHello, or to expect another one of the subsequent messages. >> > > Yes, I agree. > > It is mandatory. Pilot error on my part. > > -Ekr > > >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > --001a114fbe9812b61305268eef4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

O= n Thu, Dec 10, 2015 at 12:55 PM, Eric Rescorla <ekr@rtfm.com> wro= te:


On Thu, Dec 10, = 2015 at 12:40 PM, John Foley <foleyj@cisco.com> wrote:
While reviewing the latest TLS 1.3 draft (revis= ion 10), the description in section 6.3.3 uses the following wording:

When this message will be sent:

=C2=A0 =C2=A0 =C2=A0 If this message is sent, it MUST be sent immediately a= fter the
=C2=A0 =C2=A0 =C2=A0 ServerHello message.=C2=A0 This is the first message t= hat is encrypted
=C2=A0 =C2=A0 =C2=A0 under keys derived from ES.


The use of the word "if" implies this is an optional message. How= ever, Figure 1 in section 6.2 implies the EncryptedExtensions message is no= t optional since it's not footnoted with an asterisk. The asterisk foot= note is described as:

Indicates optional or situation-dependent messages that are not always sent= .


Can anyone comment on whether the EncryptedExtensions message is optional?= =C2=A0 If it is, should Figure 1 be updated to reflect this? Or, should the= the text in section 6.3.3 be updated to indicated this message is required= ?

This is an important detail for implementors, since the client-side state m= achine will need to know whether to expect the EncryptedExtensions message = after the ServerHello, or to expect another one of the subsequent messages.=

Yes, I agree.

It is mandatory. Pilot error on my part.

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


--001a114fbe9812b61305268eef4b-- From nobody Thu Dec 10 10:06:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AC81A8A10 for ; Thu, 10 Dec 2015 10:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, 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 pQBdcnBWNcX5 for ; Thu, 10 Dec 2015 10:06:12 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750A41A9100 for ; Thu, 10 Dec 2015 10:06:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5938; q=dns/txt; s=iport; t=1449770770; x=1450980370; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=tOiQQ4QRduUlt+h7pFlTSCcd49fyRRShGX2hJeR19Ow=; b=Y6Fty/WSwehfU7II8xCo/9FSB64C/twEQl6DaS6Gllor/sHg6qhDUO5H bHcsFc5Z4Els1gB1zqrDjkXpPGFWTUlVcuJvUnccZT66zdEDSjSnJ+PTt Dx5MTLKbu9lDQ0t4fPt1w5+CXs36CYlX1tcvXeFAHPhpyp1GNCPwvH8nx 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdBQCXvmlW/5pdJa1egzpTbr1JgWIXA?= =?us-ascii?q?QmFbgKBODkTAQEBAQEBAYEKhDUBAQQBAQEgSwoBEAsOCgkWCAMCAgkDAgECARU?= =?us-ascii?q?fEQYNBgIBAYgrDa4qkg4BAQEBAQEBAQEBAQEBAQEBAQEBAQEUBItTh3eBSQWOJ?= =?us-ascii?q?4hIjUOJJJNlIwE/hCIgNIVaAQEB?= X-IronPort-AV: E=Sophos;i="5.20,409,1444694400"; d="scan'208,217";a="216046273" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Dec 2015 18:06:09 +0000 Received: from [10.82.161.102] ([10.82.161.102]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tBAI681Y017459; Thu, 10 Dec 2015 18:06:09 GMT To: Eric Rescorla References: <5669B920.9080001@cisco.com> From: John Foley Message-ID: <5669BF2A.2070306@cisco.com> Date: Thu, 10 Dec 2015 13:06:34 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040309090701050704040609" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] EncryptedExtensions message in [draft-ietf-tls-tls13-10] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Dec 2015 18:06:14 -0000 This is a multi-part message in MIME format. --------------040309090701050704040609 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/10/2015 12:55 PM, Eric Rescorla wrote: > > > On Thu, Dec 10, 2015 at 12:40 PM, John Foley > wrote: > > While reviewing the latest TLS 1.3 draft (revision 10), the > description in section 6.3.3 uses the following wording: > > When this message will be sent: > > If this message is sent, it MUST be sent immediately after the > ServerHello message. This is the first message that is > encrypted > under keys derived from ES. > > > The use of the word "if" implies this is an optional message. > However, Figure 1 in section 6.2 implies the EncryptedExtensions > message is not optional since it's not footnoted with an asterisk. > The asterisk footnote is described as: > > Indicates optional or situation-dependent messages that are not > always sent. > > > Can anyone comment on whether the EncryptedExtensions message is > optional? If it is, should Figure 1 be updated to reflect this? > Or, should the the text in section 6.3.3 be updated to indicated > this message is required? > > This is an important detail for implementors, since the > client-side state machine will need to know whether to expect the > EncryptedExtensions message after the ServerHello, or to expect > another one of the subsequent messages. > > > Yes, I agree. > > It is mandatory. Pilot error on my part. > > -Ekr Thanks for clarifying this. I appreciate the prompt response. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --------------040309090701050704040609 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 12/10/2015 12:55 PM, Eric Rescorla wrote:


On Thu, Dec 10, 2015 at 12:40 PM, John Foley <foleyj@cisco.com> wrote:
While reviewing the latest TLS 1.3 draft (revision 10), the description in section 6.3.3 uses the following wording:

When this message will be sent:

      If this message is sent, it MUST be sent immediately after the
      ServerHello message.  This is the first message that is encrypted
      under keys derived from ES.


The use of the word "if" implies this is an optional message. However, Figure 1 in section 6.2 implies the EncryptedExtensions message is not optional since it's not footnoted with an asterisk. The asterisk footnote is described as:

Indicates optional or situation-dependent messages that are not always sent.


Can anyone comment on whether the EncryptedExtensions message is optional?  If it is, should Figure 1 be updated to reflect this? Or, should the the text in section 6.3.3 be updated to indicated this message is required?

This is an important detail for implementors, since the client-side state machine will need to know whether to expect the EncryptedExtensions message after the ServerHello, or to expect another one of the subsequent messages.

Yes, I agree.

It is mandatory. Pilot error on my part.

-Ekr
Thanks for clarifying this.  I appreciate the prompt response.
 
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--------------040309090701050704040609-- From nobody Fri Dec 11 10:53:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602891A9308 for ; Fri, 11 Dec 2015 10:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-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 tMw05DsiXJKT for ; Fri, 11 Dec 2015 10:53:04 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id A38A81A92AE for ; Fri, 11 Dec 2015 10:53:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 5BB502865 for ; Fri, 11 Dec 2015 20:53:02 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id KYfSdJeMkJMx for ; Fri, 11 Dec 2015 20:53:02 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 090FD103 for ; Fri, 11 Dec 2015 20:53:02 +0200 (EET) Date: Fri, 11 Dec 2015 20:52:58 +0200 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20151211185258.GA5451@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Subject: [TLS] TLS 1.3 and OCSP stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Dec 2015 18:53:07 -0000 When looking at stuff some more, I noticed that extension status_request_v2, which is used by OCSP stapling and is not deprecated [1]. Now, that extension uses additional handshake message type (certificate_status), which is specified to go between Certificate and SKE. Now, TLS 1.3 does not have SKE, and closest equivalent is server CertificateVerify. But OTOH, Cerficate/CertificateVerify/ Finished are supposed to form a block? Where it is supposed to go? Then there are other supported extensions that add messages. Specifically the following messages: - certificate_url: This can replace client certificate, whic is straightforward (if causing security issues by its sheer nature). - supplemental_data: There's ladder diagrams placing this just before Certificate. Where should this go in TLS 1.3 (there are undeprecated extensions that would use it)? [1] Unlike status_request, which is listed as deprecated. Was that intentional or mistake (if intentional, cert_type would also be a good to deprecate as superceded). -Ilari From nobody Fri Dec 11 17:13:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A5A1AC3F4 for ; Fri, 11 Dec 2015 17:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 NIt8iGj5aG5l for ; Fri, 11 Dec 2015 17:13:21 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0744.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:744]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6921AC3EF for ; Fri, 11 Dec 2015 17:13:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=L4nkca5VR7I6JFF1sJ5wteHH4ZA8dz2O3W4euwjScNI=; b=b/hX9LTzcZcIiH6Yxz7fsZjSdq3fN/8daaAcybPNYRMnY0+0XGBrsgIBVSdeqm4osBMl9IhZbQ8Tfv049tuMTUAVa2o5pAgL6eq/H7W+fVFlZAfmZE7IpWW8M/TfQiVXzR032u5tgICy7vYeEXGS02YCkejw6pnww3kSGctPYtA= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.337.19; Sat, 12 Dec 2015 01:13:05 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0337.024; Sat, 12 Dec 2015 01:13:05 +0000 From: Christian Huitema To: "tls@ietf.org" Thread-Topic: Keyshare extension spec Thread-Index: AdE0eKM1EhZKH59eROCP64yUPttwyw== Date: Sat, 12 Dec 2015 01:13:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [2001:4898:80e8:d::aa] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 5:xtT9VIDY01hbheC52A3ePFML6fSLwEviiEo07PTLP0BBHnqZteULPBdQnYmSrgy+sEYVW+vE5hsDwzksKVBjpUgtRnpyDjYelTlJOXGQXfzdNagppwzLeyZGqdNE/upX2PlO1/BR9XA4ZEHKBXKVCw==; 24:2vmmGEpnQdeJpfOeg8JWXlois/hAgq1NQYKVqY7ROWqD6JLAOHzjqJAPJDjeB6SlfWmx09hniOSEnlorCTranaYC6SPqwm6mWBHYyNact2o= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 07880C4932 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(51444003)(199003)(5001960100002)(10290500002)(105586002)(10400500002)(74316001)(106356001)(5005710100001)(54356999)(8990500004)(2900100001)(229853001)(2351001)(10090500001)(99286002)(76576001)(450100001)(50986999)(97736004)(110136002)(5003600100002)(107886002)(1220700001)(1096002)(101416001)(5004730100002)(92566002)(5008740100001)(5002640100001)(33656002)(86612001)(86362001)(77096005)(189998001)(2501003)(81156007)(40100003)(102836003)(11100500001)(6116002)(122556002)(1730700002)(586003)(87936001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2015 01:13:05.1062 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 Archived-At: Subject: [TLS] Keyshare extension spec X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Dec 2015 01:13:25 -0000 I am looking at the specification of the key share extension, section 6.3.2= .3 of the 1.3 draft. I think that the behavior is somewhat underspecified. = The spec says:=20 ...Clients MAY omit this extension from the ClientHello, and in response to= this, servers MUST send a HelloRetryRequest requesting use of one of the g= roups the client offered support for in its "supported_groups" extension. I= f no common supported group is available, the server MUST produce a fatal "= handshake_failure" alert. I am concerned with the hypothetical case in which the client sends a list = of groups in the "named group" extension but only sends keys for a subset o= f these groups in the "key share" extension. For example, a client might pr= opose secp256r1 and secp384r1 in the named group extension, leading the ser= ver to select secp256r1, but only provide a key for secp384r1 in the key sh= are extension. The server has two options: * produce a fatal handshake failure alert, because no common supported grou= p is available, * or, send a HelloRetryRequest requesting use of one of the groups the clie= nt offered support for, secp256r1 in the example. Which is the correct interpretation? Is one of these behaviors preferred, o= r are both available? Also, what is supposed to happen if the client sends an empty Key Share ext= ension? Or, if its listed key share extensions list keys for groups that ar= e not indicated in the "named group" extension? -- Christian Huitema From nobody Fri Dec 11 19:26:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587DA1ACDF5 for ; Fri, 11 Dec 2015 19:26:52 -0800 (PST) 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 8i0vVF5DBTC7 for ; Fri, 11 Dec 2015 19:26:50 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5771ACDEB for ; Fri, 11 Dec 2015 19:26:50 -0800 (PST) Received: by qkht125 with SMTP id t125so67267884qkh.3 for ; Fri, 11 Dec 2015 19:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=+oW06U62FC8PL6O2reqfGLdXODfWiqo28OiZkl9D7EE=; b=DeQFLIhHqW9ipIytmUnORteXkKUMw1hmHpvLXu6KxaumUR9NiyTfRXkCkB3TUr4deA 76EE6DXKT4F//xR+L69SC6QXdwEBZvvTbFa31ln0MkyLFmjERvwo3Up9CprDuXtR72RS 4+9HAJdcb3u2VURcPLYNkLcook1eT2YD6U+5Q3yA00UAYQDsHkpN2NPusd22z9LzdbAD F+fJFUiQ5/w/u3H0bCRD4Ys5z+55YJkWra62J3FMiKWFyTbdFJKzAKu0dmK7PPt/CtVR Czn4rCWv7mCj9tvd8DhG8/Bo73x0Iewqw37LDAZkE0/dMMseedWxF3FdX0ucBFmyiO9S sotA== X-Received: by 10.55.79.207 with SMTP id d198mr26495421qkb.49.1449890809776; Fri, 11 Dec 2015 19:26:49 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id k9sm9464312qgd.21.2015.12.11.19.26.48 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 11 Dec 2015 19:26:48 -0800 (PST) From: Dave Garrett To: Christian Huitema Date: Fri, 11 Dec 2015 22:26:46 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201512112226.47268.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Keyshare extension spec X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Dec 2015 03:26:52 -0000 On Friday, December 11, 2015 08:13:05 pm Christian Huitema wrote: > I am looking at the specification of the key share extension, section 6.3.2.3 of the 1.3 draft. I think that the behavior is somewhat underspecified. The spec says: > > ...Clients MAY omit this extension from the ClientHello, and in response to this, servers MUST send a HelloRetryRequest requesting use of one of the groups the client offered support for in its "supported_groups" extension. If no common supported group is available, the server MUST produce a fatal "handshake_failure" alert. There's some cruft in the current draft leftover from ekr and I waffling back/forth on whether to omit or send an empty extension when requesting server selection. (was pointed out on this list by someone else a couple weeks ago) We eventually decided on empty. I have a PR pending review that fixes the merge mistakes and clarifies some bits. https://github.com/tlswg/tls13-spec/pull/349/files > I am concerned with the hypothetical case in which the client sends a list of groups in the "named group" extension but only sends keys for a subset of these groups in the "key share" extension. For example, a client might propose secp256r1 and secp384r1 in the named group extension, leading the server to select secp256r1, but only provide a key for secp384r1 in the key share extension. The server has two options: > > * produce a fatal handshake failure alert, because no common supported group is available, > * or, send a HelloRetryRequest requesting use of one of the groups the client offered support for, secp256r1 in the example. > > Which is the correct interpretation? Is one of these behaviors preferred, or are both available? The latter: HelloRetryRequest is the required response. (See also the PR noted above.) The retry mechanism essentially allows key shares to be provided on-demand. Servers selecting a group that is supported, but not provided, request it via the HelloRetryRequest. > Also, what is supposed to happen if the client sends an empty Key Share extension? With the pending changes this is the explicit HelloRetryRequest request case. Lack of the extension when offering suites requiring it a fatal "missing_extension" alert. (switching to supplying an empty extension when requesting a retry makes this simpler) > Or, if its listed key share extensions list keys for groups that are not indicated in the "named group" extension? I have a "MUST NOT" for doing that in the pending PR. In order to be thorough, I've just amended it with a specific fatal alert to throw. Though other mechanisms should catch an attempt to inject a bogus key share, implementations not checking for and erroring on unsupported keys here sounds like a recipe for badness. Dave From nobody Fri Dec 11 20:54:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA561A007A for ; Fri, 11 Dec 2015 20:54:39 -0800 (PST) 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 pCi75Wu6z5pf for ; Fri, 11 Dec 2015 20:54:37 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1DB1A006F for ; Fri, 11 Dec 2015 20:54:37 -0800 (PST) Received: by mail-ig0-x233.google.com with SMTP id su19so52653439igc.0 for ; Fri, 11 Dec 2015 20:54:37 -0800 (PST) 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=zqabcPWae9ddGBOPeuMs2hVJyJ+OfTOSLddyxSTrKoI=; b=N+NgvHnwAoZjb1JwV4tcw+1nVdV6XlKomFLE+0HpxOjJf5Ujmh7AA9Z+sAUz48tZ54 hB/ng9IwzM1exJgPYVibl/dKBV/Bl0ZARBq7u/EuFP37kcJSeo5yN1S4eNlntntzg6kw L1dxUc1ISgycGdZZfC/4jmfcqwH2fvdtHLUrvEHlkGSa3gFqM2NqMyHka+F3ovPCKiuU 83elcHcIZVh2YgYoUGPpKr/LMRnYBWdozWwZqcTsIgcSQoU4fm2ZJixsWWG+6AhQHmJb 5CyqJT3qwbWS5MFyxP4yj+pv04mBDjs2vl8RB9rTIcrN9J2lbuEmoGLT+crAS6je1bSr LM6w== MIME-Version: 1.0 X-Received: by 10.50.20.8 with SMTP id j8mr8571279ige.94.1449896076860; Fri, 11 Dec 2015 20:54:36 -0800 (PST) Received: by 10.36.149.130 with HTTP; Fri, 11 Dec 2015 20:54:36 -0800 (PST) In-Reply-To: <20151211185258.GA5451@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151211185258.GA5451@LK-Perkele-V2.elisa-laajakaista.fi> Date: Sat, 12 Dec 2015 15:54:36 +1100 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 and OCSP stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Dec 2015 04:54:39 -0000 I think that the best way to deal with the status_request_v2 extension is to make it a proper part of the TLS 1.3 messages, probably Certificate or CertificateVerify. This is a fairly heavily important extension. On 12 December 2015 at 05:52, Ilari Liusvaara wrote: > When looking at stuff some more, I noticed that extension > status_request_v2, which is used by OCSP stapling and is not deprecated > [1]. > > Now, that extension uses additional handshake message type > (certificate_status), which is specified to go between Certificate > and SKE. Now, TLS 1.3 does not have SKE, and closest equivalent is > server CertificateVerify. But OTOH, Cerficate/CertificateVerify/ > Finished are supposed to form a block? Where it is supposed to go? > > Then there are other supported extensions that add messages. > Specifically the following messages: > > - certificate_url: This can replace client certificate, whic is > straightforward (if causing security issues by its sheer nature). > - supplemental_data: There's ladder diagrams placing this just > before Certificate. Where should this go in TLS 1.3 (there are > undeprecated extensions that would use it)? > > > [1] Unlike status_request, which is listed as deprecated. Was > that intentional or mistake (if intentional, cert_type would also be a > good to deprecate as superceded). > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Dec 12 02:29:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A891A014F for ; Sat, 12 Dec 2015 02:29:15 -0800 (PST) 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 gq5JI0giwENI for ; Sat, 12 Dec 2015 02:29:12 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E7031A014E for ; Sat, 12 Dec 2015 02:29:12 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id l68so3264333wml.0 for ; Sat, 12 Dec 2015 02:29:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type; bh=zM4nz6fFR7uodl3dc21OrmEOAfoG65NkWj8AQWI4K5k=; b=rl+xk/kH2Xg/NotE19k0PH1rtJgmRzMwn3K7W04xCRcvy6Q1x0PPf0QBc11vY3a8he UH3HqifbaGeEb5QxBaIEkMaQozmcp6ctFl1er1XH+OYkb8c9PRqhMyOSYJ50eerP/39F 8VuEjvdUv2duKi/tXtC/gYXF7pzC2J6QasBr/nCnhil+NrlCjItpnYaUuTNKdIfD2HOY r1d7jbMTxB/EH9mciCRLGNsfs1m1VHCdMuP9kD36CI3YkLD6XDATvHtbiq5Ck9Y8kuOY qHiKpkin1nC7o/kWiQpw1r+eZlWJUm91Rnf4bjWcU7jTMolE5w6iHJW6mSSJYGaXH5lS B1XQ== X-Received: by 10.28.8.15 with SMTP id 15mr12297901wmi.50.1449916150726; Sat, 12 Dec 2015 02:29:10 -0800 (PST) Received: from proz.dclient.lsne.ch (85-218-12-53.dclient.lsne.ch. [85.218.12.53]) by smtp.gmail.com with ESMTPSA id q4sm20694733wja.6.2015.12.12.02.29.09 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Dec 2015 02:29:09 -0800 (PST) To: "tls@ietf.org" From: Bryan A Ford X-Enigmail-Draft-Status: N1110 Message-ID: <566BF6F4.7050100@gmail.com> Date: Sat, 12 Dec 2015 11:29:08 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000803080806000909050504" Archived-At: Subject: [TLS] Prototype of TLS 1.3 records, padding, and optional headerless records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Dec 2015 10:29:15 -0000 This is a cryptographically signed message in MIME format. --------------ms000803080806000909050504 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Since a lot of the skepticism toward my encrypted-headers proposal constituted worries whether the benefits are worth the implementation cost/complexity, I decided to implement it and find out what that cost and complexity actually is. See this github repo: https://github.com/bford/nss Here you'll find a snapshot of Mozilla NSS/NSPR, with three branches: (a) current baseline version supporting only TLS 1.2 records; (b) a version that adds support for the currently-specified TLS 1.3 record format with the encrypted content-type trailer and padding within the AEAD; and (c) a further extension to support optional "headerless" records. This doesn't implement all the other new stuff in TLS 1.3 such as negotiation, 0-RTT, etc. - only the record-layer changes. --- Observations from implementing TLS 1.3 records: The baseline...master diff (https://github.com/bford/nss/pull/1/files) represents the changes that appear needed to get from TLS 1.2 records to TLS 1.3 record format, with padding of records to a constant size for traffic analysis protection. I set the fixed padded record length (TLS13_PAD_FRAGMENT_LENGTH) to 256 bytes "just because", but change it to whatever you like; I don't have any fish to fry regarding the specific "best" value. 512 and 1024 also seem like reasonable choices, with obvious tradeoffs between wasted bytes padding small messages versus the bandwidth and processing overheads of fewer bytes per record. Measuring implementation complexity simplistically by line count, this diff constitutes +92-14=3D78 lines (92 added, 14 removed) - nothing too serious. Subjectively, the main implementation came from adding the 1-byte internal content-type trailer in the first place, which means having to copy the input cleartext into the write buffer in order to fiddle with it before passing it to the AEAD encryptor. Thus, because of this 1-byte content-type trailer (even with no padding), we can no longer just encrypt directly from the caller-provided input into the ciphertext buffer but have to copy the cleartext first, unless the AEAD API supports scatter/gather (which NSS's doesn't and I expect most probably won't). This doesn't seem like a big problem to me and I definitely consider the benefits of the encrypted content type and record padding to be worth this minor cost. And in practice I doubt it'll cause any actual noticeable performance degradation because a copy-A-to-B-then-encrypt-in-place-at-B is going to have a pretty similar cache footprint as an encrypt-from-A-to-B. TLS 1.3 also already changes the way the pseudo-header is calculated for MAC purposes; I didn't yet fully implement those changes, but did already need to move the pseudo-header calculation on the send side until a bit later when the length of the ciphertext is known. --- Headerless records extension: The other pull request (https://github.com/bford/nss/pull/2/files) represents the further delta needed to implement a further simplified version of my last "encrypted headers" proposal, which in this incarnation becomes "headerless records". Since TLS 1.3 is already adding a 1-byte mandatory encrypted trailer within each record (the encrypted content-type), I simply extended this to a 3-byte trailer, in which the first two bytes indicate: - If zero, the next record (following this one) has the usual 5-byte TLS header and its length is defined by that header as usual. - If nonzero, the next record has *no* TLS header at all, and its length is defined by this value. By combining the "next-record-length" into the encrypted trailer that TLS 1.3 is adding anyway, the changes required are pretty minimal. By my count, this is a delta of +40-8=3D32 lines, which at least to me seems= pretty insignificant in terms of implementation complexity. And implementations could be even simpler by not implementing the send-side logic at all and simply setting all next-record-length fields in the trailers to zero, attaching headers to all records as before. The only minor point of "implementation pain" is the need to add the appropriate inter-record state variables (writeNextLength and readNextLength), but the handling of these are not fundamentally any different from the state needed to keep track of sequence numbers across records for example. Making headerless records optional, selected by the trailer in the prior record as defined above, offers several nice benefits: - It address the concerns that have been raised (though unsubstantiated so far with any concrete evidence) about breaking middleboxes that want to parse traditional TLS record streams. TLS implementations that are paranoid to this degree about breaking middleboxes can simply always set the next-header-length field in the trailer to 0 and send cleartext record headers for every TLS record just as before. - We don't need to do anything special to handle the "first record" case: i.e., we neither need to specify a standard "first record length" nor add a first-record-length field to one of the negotiation packets. Instead, the first AEAD-encrypted record is simply transmitted with a 5-byte header as usual, but the sender can omit the headers from subsequent records if it chooses to. - A TLS 1.3 implementation that doesn't want to bother "predicting" or "committing to" a next-record-length beyond a SSL_Write() boundary can simply set the next-record-length field to zero in the last record of the current write, so the first record in the next SSL_Write() will including a header determining its size as before. This isn't ideal in terms of traffic analysis protection, but it's an implementation option. - FWIW, when the sender transmits headerless records, the encoding saves 2 bytes per record with respect to TLS 1.2 (saving the 5-byte cleartext header but adding the 3-byte encrypted trailer). --- Implications on padded record transmission: Finally, while implementing this extension I realized a further general benefit of headerless transmission: it can make the use of padding for traffic analysis protection more bandwidth-efficient. With cleartext headers, to achieve the traffic analysis benefits of padding we must ensure that every transmitted record has *exactly* the same ciphertext length, since any variation will produce a readily fingerprintable pattern in cleartext. This creates tradeoffs, as noted above. Padding to a smaller fixed size (e.g., 256 bytes) adds less bandwidth overhead to small messages such as typical HTTP requests but incurs the cost of a MAC tag, nonce, TLS headers/trailers etc once every 256 bytes - for AES-GCM this is about an 11% bandwidth overhead with 256-byte records. Padding to a larger fixed size (e.g., 1024) reduces the bandwidth overhead for bulk data transmission such as large HTTP responses (e.g., to about 3% overhead with 1024-byte records), at a cost of adding a lot of bandwidth overhead to tiny HTTP requests or status-indication responses, which are also common. With headerless records, in contrast, we can pick a relatively small ciphertext length padding granularity (e.g., 256 bytes), but then the sender can transmit records whose sizes are any *multiple* of this granularity, because N consecutive 256-byte ciphertexts are now cryptographically indistinguishable from a single N*256-byte ciphertext. Thus, we get the bandwidth-efficiency benefits of small records by avoiding the need to add too much padding to small messages, plus the bandwidth-efficiency benefits of larger records for bulk transmission. For example, we can send a large message mostly consisting of ~16384-byte records, each containing only one MAC tag and internal TLS 1.3 trailer (though an eavesdropper won't know that), reducing the bandwidth overhead in the AES-GCM case from 11% to 0.2%. There are two minor caveats to this: - In the specific case of AES-GCM, it looks like TLS 1.2 uses AES-GCM with explicitly transmitted nonces, which are clearly distinguishable from random values and hence will break the above benefits. The solution is simple, however: simply make TLS 1.3 use AES-GCM (and other AEAD schemes) without explicit nonces. These nonces can be calculated implicitly by sender and receiver just as easily without explicit transmission, and all the necessary integrity-checking happens via the "additional_data" pseudo-header anyway. (In fact perhaps TLS 1.3 already eliminates the explicit nonce - I don't see any mention of it in the new record spec anyway, the only question is whether it's still in the AES-GCM-specific specs, which I haven't looked at closely and don't know if they'll be updated wrt TLS 1.3 or not.) - Even if N 256-byte ciphertexts in a TLS 1.3 stream are cryptographically indistinguishable from one N*256-byte ciphertext, if the TLS sender implementation transmits these in a single OS write(), the OS's TCP stack may (or may not, depending on circumstances) still reveal this difference by segmenting transmitted TCP segments differently. There are several obvious solutions to this, however: (1) The TLS implementation could prepare the N*256-byte ciphertext but then transmit it using N separate 256-byte write() calls to the underlying TCP stack. This might (again depending on the TCP stack) increase the TCP-level overhead by sending many smaller-than-necessary TCP segments, but is a fully OS-independent solution, and we still save the TLS-level bandwidth overhead (one MAC tag etc rather than N). (2) Better, at least on Linux systems, the TLS implementation could simply enable the TCP_CORK socket option, causing the kernel to delay the transmission of incomplete (less-than-MTU-sized) TCP segments slightly in hopes of "filling" them. This way, the TLS sender will always produce continuous streams of MTU-sized TCP segments for all "bursts" of transmission of any number of TLS records. The downside is that the kernel-imposed delay can add a bit of latency (I understand around 200ms) to the transmission of the very last, incomplete segment in a burst, thus perhaps adding up to 200ms to the total request/response latency of a round-trip interactive exchange. (3) Still better, again on Linux systems, the TLS implementation could send records using send() instead of write(), and set the MSG_MORE flag on all records except for the last record just before the connection goes idle (no more data to transmit). Figuring out when a connection is "going idle" may require some heuristics or hints from the application, but can ensure that bursts are transmitted as a fully uniform series of MTU-size segments without incurring any added delay at the end. --- OK, congratulations and thanks to anyone who persisted through all that. I hope this will help understand the implementation complexity and tradeoffs both of the currently-specified TLS 1.3 record layer and the proposed headerless records features. Comments? Thanks Bryan --------------ms000803080806000909050504 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIxMjEwMjkwOFowLwYJKoZIhvcNAQkEMSIEIJ8vZW/xL6um2sFtTJHzwweD7Mux//DfHotI XOPWp0QZMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBAJuCgYoPhZDnJbnT MFCD/wIJKyao/i8At1ln0qIitA8Z/E9JCYXwEYKk8ltJYkNL+P7LBHPI94337eU9jJlqWAwo NzMOt/BEOM+QeOpKLT9Loln7RXEBVXfwkpgFt6NhIjHDiVVCYR0A9tsDlJ/1Ge7p6Tus7bH6 25VYt74gBG5QC6iBa44YaEXJYXrpDuMPSX70VZvMDuGpAiEALOlhlGNn8/fgBdaeSenSkavy g0le3wd0cc3haKW15Mr13KLeV07dWMcOf3PGFKSq1uE8I6xsFtAim4+iO+A0Y8+EsZfnqEi7 hr7CiF4TA/pGDvBsNUJplJdcK6Y8tjPmG+lBo78AAAAAAAA= --------------ms000803080806000909050504-- From nobody Sat Dec 12 02:46:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A321A03D5 for ; Sat, 12 Dec 2015 02:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, T_RP_MATCHES_RCVD=-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 2N6_yFtGXW4q for ; Sat, 12 Dec 2015 02:46:04 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 33F4F1A03A2 for ; Sat, 12 Dec 2015 02:46:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 9764C42E; Sat, 12 Dec 2015 12:46:02 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id eTBl5fKFnFe6; Sat, 12 Dec 2015 12:46:02 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 4DC3E230D; Sat, 12 Dec 2015 12:46:02 +0200 (EET) Date: Sat, 12 Dec 2015 12:45:58 +0200 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20151212104558.GA6039@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151211185258.GA5451@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 and OCSP stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Dec 2015 10:46:06 -0000 On Sat, Dec 12, 2015 at 03:54:36PM +1100, Martin Thomson wrote: > I think that the best way to deal with the status_request_v2 extension > is to make it a proper part of the TLS 1.3 messages, probably > Certificate or CertificateVerify. This is a fairly heavily important > extension. If one wants to incorporate it, I would think Certificate for two reasons: - So CertificateVerify signs it without hacks. It is easier to analyze things if the only thing not covered are the signature and Finished. - Because Certificate message is modifed anyway for authentication contexts (CertificateVerify is not sent if the client refuses authentication, and server should be able to tell which authentication is refused). Something like: struct { opaque certificate_request_context<0..255> ASN1Cert certificate_list<0..2^24-1> opaque wrapped_status<0..2^24-1> } Certificate; Where wrapped_status payload is what would be the CertificateStatus message payload (empty if CertificateStatus would not have been sent). -Ilari From nobody Sat Dec 12 04:08:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5651A7030 for ; Sat, 12 Dec 2015 04:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 FV6JNlevDlUF for ; Sat, 12 Dec 2015 04:08:25 -0800 (PST) Received: from mail.mehnert.org (mail.mehnert.org [213.73.89.200]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4563C1A7034 for ; Sat, 12 Dec 2015 04:08:25 -0800 (PST) Received: from [192.168.0.11] (cpc30-cmbg15-2-0-cust247.5-4.cable.virginm.net [86.4.51.248]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "hannes@mehnert.org", Issuer "mehnert root CA" (not verified)) by mail.mehnert.org (Postfix) with ESMTPS id A294E19F6 for ; Sat, 12 Dec 2015 13:08:22 +0100 (CET) To: "tls@ietf.org" From: Hannes Mehnert Openpgp: id=11B5464249B5BD858FFF6328BC896588DF7C28EE X-Enigmail-Draft-Status: N1110 Message-ID: <566C0E25.5080703@mehnert.org> Date: Sat, 12 Dec 2015 12:08:05 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha384; protocol="application/pgp-signature"; boundary="wGrkF2RVko0XO0xVpar5qXRuG5vNCECmR" Archived-At: Subject: [TLS] ServerHello layout in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Dec 2015 12:08:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wGrkF2RVko0XO0xVpar5qXRuG5vNCECmR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, while implementing the TLS 1.3 draft, I came across the modified ServerHello message - it does neither contain a SessionID nor a CompressionMethod field. This makes code which supports both TLS 1.3 and earlier versions more complicated*: a client sending out a ClientHello does not know which protocol version the server is willing to talk. Thus, depending on the protocol version inside of the server hello, the remainder of the packet needs to be parsed. I'm not sure whether it is worth to safe two bytes (empty SessionID and NULL CompressionMethod) to introduce such an intrinsic dependency. Is there a reason behind this change, apart from cleanup? Thanks, Hannes *: It is not hard to implement a conditional here, but it makes the control flow of the code unnecessary complex imho, especially since up to TLS-1.2 client and server hello can be parsed by the same function (modulo the list vs single ciphersuite and compression method, see https://github.com/mirleft/ocaml-tls/blob/99384104e09b21a736872854e0a6961= 5a4545780/lib/reader.ml#L295-L327). --wGrkF2RVko0XO0xVpar5qXRuG5vNCECmR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCQAGBQJWbA4lAAoJELyJZYjffCjuwGcP/2n0tpIppRUqIYZWK3Nl1bOb 2G+fVETpjo3fargbda4EUjO84F0sgh8Xt7TcEeu0+6s4qWpIQOSYwRkyjshIgYQS 2pD+P7eQtosaG1GBpUN62B+jd8SLClbOwHZERuRPcd9F6Ru/8zciP8XkT2w9zp72 0GjVWPtAiZaEKPgUifISncNPsEPl7cItfXo5dTJVgMhhpNaon14muKokl/SMIKqY 3b0LPZp2yzdl+s75FjUv7Jd0LBOpgvLllQmjT4rBcUpBL4RHzdBj+mXhh3GJImKu RyaqT/pSmT1XXsU4Ot7M8mL7yYHBFb/nFVRDbs4/WYQEZ9G9ocWS18+WY78YUUBZ DhH3U94dxKqbgulKMwVxVpUkkZd+/dZImxiotYWF/yPITKkSn0kkZ0cruhugs52N aCgaVjHgk+a87bT19epvgBQFTtuJcqbuynxPuBBqN6gBluMJUYUhNFMAyYUFH2WV dSIaxFZal4xsZvBskORD7r1rn+9s454eFzLJAww1YaX3PGApV1psBCn5ajTMneSO XOwMFsR1RIxUqFYjr9ytoz74f0bDrUzy4gLYYTKVepNSf/wKn/SMQ2jbdKYtsp4N cjk0gMz134nOYbshY0uGYJQNLL7hmZQpbHLym0Ca3bltxzdDZXKaO1t5vdl+qyA4 q7weczuj/57iq0jXhAjR =I6E3 -----END PGP SIGNATURE----- --wGrkF2RVko0XO0xVpar5qXRuG5vNCECmR-- From nobody Sat Dec 12 07:02:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F221A87A1 for ; Sat, 12 Dec 2015 07:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 RpeliMnGYAPH for ; Sat, 12 Dec 2015 07:02:39 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8088C1A8795 for ; Sat, 12 Dec 2015 07:02:39 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5FEBB4250B4; Sat, 12 Dec 2015 15:02:38 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 49BD74ECA8; Sat, 12 Dec 2015 15:02:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1449932558; bh=1/76lMZymThcupM0nim8B7ULLy1w/cHVVRAwycDhwAY=; l=260; h=From:To:CC:Date:References:In-Reply-To:From; b=wAAfi5zyV7Oh4VvjMzBLCi6bqlUzN75CBsDKj7cOS+I1dRc6+GF5imQ07eoLz7juF 7rvokvyixC348ovx4avlA7yuIVqPzAjQ8EeGPfmK/hOd+cvO/FkBz6lYxFzEt0QJ3P SGA8pg4AKkhSl1gr+QRoHgGlNWGs4SIHq8kCKIaw= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 47486202D; Sat, 12 Dec 2015 15:02:38 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sat, 12 Dec 2015 10:02:37 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Sat, 12 Dec 2015 10:02:37 -0500 From: "Salz, Rich" To: Martin Thomson , Ilari Liusvaara Thread-Topic: [TLS] TLS 1.3 and OCSP stapling Thread-Index: AQHRNEUwS/Eqx0yuMEKoNWpdufN8Jp7HHa0AgABWAmA= Date: Sat, 12 Dec 2015 15:02:37 +0000 Message-ID: <2cef9d92f1e344f09053fc4efbe2c381@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20151211185258.GA5451@LK-Perkele-V2.elisa-laajakaista.fi> 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: [172.19.32.140] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 and OCSP stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Dec 2015 15:02:41 -0000 =20 > I think that the best way to deal with the status_request_v2 extension is= to > make it a proper part of the TLS 1.3 messages, probably Certificate or > CertificateVerify. This is a fairly heavily important extension. I'd be in favor of this. From nobody Sat Dec 12 12:28:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132C21A8F50 for ; Sat, 12 Dec 2015 12:28:43 -0800 (PST) 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, HTML_MESSAGE=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 luYAG-l_-yAi for ; Sat, 12 Dec 2015 12:28:41 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62E81A8F4E for ; Sat, 12 Dec 2015 12:28:41 -0800 (PST) Received: by qkfb125 with SMTP id b125so86416106qkf.2 for ; Sat, 12 Dec 2015 12:28:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zUuMy1Oo5eLTAm1SD9XwMrv9WpaNNPAJK5bSE9EfqI0=; b=puhKcipqrh66G0nCr96goHXHR4beOcS/Vh36VqR0MLBEOYfkQjg7zs0XHuqN2ujtub ahDmpm32zA8eTWMvLBLK3Wa9otjHpV+1+vrbbUeVrPJkXBPahclanFBUJijlCVoRFlcl 3xLd0Pxekn9dV7WzhJK7/GGYdGQ9375aAnKD0A+okX9iu/tUAuI/8vRiPta/aA1AU9ER eQuTSkgCciMcKbMrPaPZQ7epWNz4ncpnszKY4qQGD99Z/erTbeJKMtStYX8CafBh4vYg Sdt4l+1LNq5HXkJdOr9WUIpMWVH0iiWtE9kPP32OXo4QtNa1tOA8JmWnLY5Zi6j0W+7R XViQ== 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=zUuMy1Oo5eLTAm1SD9XwMrv9WpaNNPAJK5bSE9EfqI0=; b=kU+gi0tTUEC4p0jvFkU9rjZwjZnG4aaM+hTeBMTEv1LaFYRuDTa4d/glPSvarmbZOL mg3BLH5B6tBJVxSLK0rAtL3vAuHiLMtV8c4I/LYnbcVYJ2veqB7aXrOe/2B13/pACjQl TqDdabddAdQ+IoehkHBK0TeLUkAsGsCaeNgvvoIGhs6wnvbhFLkYF3U05/4R1Tr0DVkY DFaRiju732+QsP+XGExUBM1P/BXuz94uVEeAuMBNmpHeA1ilTXE8bKtACW6Kl5NyAx5t V0RqSRN0swaJb53yNul9dVUOI7m/Ghx27NO7SwZb/hPpurT+OUiCiRBVL3C7+U7Cpsdl dl7w== X-Gm-Message-State: ALoCoQlR3YLICq4jyVgsuIkXdUi3ODWHht6IYv/NOPcBzHGlYEsFtfZv3UiwKsuW2mANfxxZYntoYyI0Jpt9MIviux8GnpB0Mg== X-Received: by 10.129.79.87 with SMTP id d84mr6355732ywb.115.1449952120788; Sat, 12 Dec 2015 12:28:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Sat, 12 Dec 2015 12:28:01 -0800 (PST) In-Reply-To: <566C0E25.5080703@mehnert.org> References: <566C0E25.5080703@mehnert.org> From: Eric Rescorla Date: Sat, 12 Dec 2015 12:28:01 -0800 Message-ID: To: Hannes Mehnert Content-Type: multipart/alternative; boundary=001a114dc3601a07650526b9496a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] ServerHello layout in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Dec 2015 20:28:43 -0000 --001a114dc3601a07650526b9496a Content-Type: text/plain; charset=UTF-8 On Sat, Dec 12, 2015 at 4:08 AM, Hannes Mehnert wrote: > Hi, > > while implementing the TLS 1.3 draft, I came across the modified > ServerHello message - it does neither contain a SessionID nor a > CompressionMethod field. This makes code which supports both TLS 1.3 > and earlier versions more complicated*: a client sending out a > ClientHello does not know which protocol version the server is willing > to talk. > > Thus, depending on the protocol version inside of the server hello, the > remainder of the packet needs to be parsed. > > I'm not sure whether it is worth to safe two bytes (empty SessionID and > NULL CompressionMethod) to introduce such an intrinsic dependency. > > Is there a reason behind this change, apart from cleanup? > I'm not aware of ay reason besides cleanup. I don't feel strongly about the current state. -Ekr > Thanks, > > Hannes > > *: It is not hard to implement a conditional here, but it makes the > control flow of the code unnecessary complex imho, especially since up > to TLS-1.2 client and server hello can be parsed by the same function > (modulo the list vs single ciphersuite and compression method, see > > https://github.com/mirleft/ocaml-tls/blob/99384104e09b21a736872854e0a69615a4545780/lib/reader.ml#L295-L327 > ). > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114dc3601a07650526b9496a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Dec 12, 2015 at 4:08 AM, Hannes Mehnert <<= a href=3D"mailto:hannes@mehnert.org" target=3D"_blank">hannes@mehnert.org> wrote:
Hi,

while implementing the TLS 1.3 draft, I came across the modified
ServerHello message - it does neither contain a SessionID nor a
CompressionMethod field.=C2=A0 This makes code which supports both TLS 1.3<= br> and earlier versions more complicated*:=C2=A0 a client sending out a
ClientHello does not know which protocol version the server is willing
to talk.

Thus, depending on the protocol version inside of the server hello, the
remainder of the packet needs to be parsed.

I'm not sure whether it is worth to safe two bytes (empty SessionID and=
NULL CompressionMethod) to introduce such an intrinsic dependency.

Is there a reason behind this change, apart from cleanup?
<= div>
I'm not aware of ay reason besides cleanup. I don= 9;t feel strongly
about the current state.

-Ekr


Thanks,

Hannes

*: It is not hard to implement a conditional here, but it makes the
control flow of the code unnecessary complex imho, especially since up
to TLS-1.2 client and server hello can be parsed by the same function
(modulo the list vs single ciphersuite and compression method, see
https://github.com/mirleft/ocaml-tls/blob/99384104e09b21a736872854e0a= 69615a4545780/lib/reader.ml#L295-L327).


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


--001a114dc3601a07650526b9496a-- From nobody Sat Dec 12 16:15:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78B41ACC87 for ; Sat, 12 Dec 2015 16:15:03 -0800 (PST) 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 QuZcj3P_-f8g for ; Sat, 12 Dec 2015 16:15:01 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979F31AC447 for ; Sat, 12 Dec 2015 16:15:01 -0800 (PST) Received: by qgew101 with SMTP id w101so21957984qge.2 for ; Sat, 12 Dec 2015 16:15:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=TYO1kjtk9GG+zZomjB3mlONTWK6Q+d6Mmk5u/XeoARU=; b=AIhL/yz1kynUjf370EuUFl9E5iGCOhMCaAhN0Zqg+k0U0Oqjs/AsJccmwqZdxMLmT2 3BpcSSXEXrar/+ksZE6i0N53cw3pevW8zbbC+zfEkWkE0sXLdHLzmbCsFYI90RrSmtxz +rPV5FdMEJ3vKNXnURemdHa5nVb5sAMQGxOpuLNZ7Oe/XkaZ7eIxT9fGSbr7xBNCX2dN WQS1I7S4xFFFxjntlgJEfdfAEHIqneURS2nTuABH49qcmNzqeQtKHe1s23rz53OP5lqx CAW1StHtBlAlwIL2KuH/PKiUcxpl3A4LY/HP/ShfMSgRdz1bnI6DKGlI4+IRpvOujZj/ Pz8w== X-Received: by 10.140.236.211 with SMTP id h202mr23769847qhc.7.1449965700828; Sat, 12 Dec 2015 16:15:00 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id g63sm11078415qgd.5.2015.12.12.16.14.59 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 12 Dec 2015 16:14:59 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Sat, 12 Dec 2015 19:14:58 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <566C0E25.5080703@mehnert.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201512121914.58569.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] ServerHello layout in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Dec 2015 00:15:03 -0000 On Saturday, December 12, 2015 03:28:01 pm Eric Rescorla wrote: > On Sat, Dec 12, 2015 at 4:08 AM, Hannes Mehnert wrote: > > while implementing the TLS 1.3 draft, I came across the modified > > ServerHello message - it does neither contain a SessionID nor a > > CompressionMethod field. This makes code which supports both TLS 1.3 > > and earlier versions more complicated*: a client sending out a > > ClientHello does not know which protocol version the server is willing > > to talk. > > > > Thus, depending on the protocol version inside of the server hello, the > > remainder of the packet needs to be parsed. > > > > I'm not sure whether it is worth to safe two bytes (empty SessionID and > > NULL CompressionMethod) to introduce such an intrinsic dependency. > > > > Is there a reason behind this change, apart from cleanup? > > I'm not aware of ay reason besides cleanup. I don't feel strongly > about the current state. Leaving cruft around increases risk of mistakes; if you leave in obsolete fields when they're not needed anymore, a dumb implementation might accidentally use it or be tricked into doing so by an attacker. That said, the world will not end if yet more kludgy placeholders are needed. I'd prefer to avoid that if at all possible, though. Dave From nobody Mon Dec 14 04:29:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3A21ACDE5 for ; Mon, 14 Dec 2015 04:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, 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 glflqsTOoAWv for ; Mon, 14 Dec 2015 04:29:29 -0800 (PST) Received: from mmextmx2.mcr.colo.comodoca.net (mail1.comodoca.com [91.209.196.72]) (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 02A0D1ACDDC for ; Mon, 14 Dec 2015 04:29:28 -0800 (PST) Received: (qmail 28351 invoked by uid 1004); 14 Dec 2015 12:29:26 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 14 Dec 2015 12:29:26 +0000 Received: (qmail 11239 invoked by uid 1000); 14 Dec 2015 12:29:26 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 14 Dec 2015 12:29:26 +0000 To: "Salz, Rich" , Martin Thomson , Ilari Liusvaara References: <20151211185258.GA5451@LK-Perkele-V2.elisa-laajakaista.fi> <2cef9d92f1e344f09053fc4efbe2c381@usma1ex-dag1mb1.msg.corp.akamai.com> From: Rob Stradling Message-ID: <566EB625.7060402@comodo.com> Date: Mon, 14 Dec 2015 12:29:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <2cef9d92f1e344f09053fc4efbe2c381@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 and OCSP stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Dec 2015 12:29:32 -0000 On 12/12/15 15:02, Salz, Rich wrote: >> I think that the best way to deal with the status_request_v2 extension is to >> make it a proper part of the TLS 1.3 messages, probably Certificate or >> CertificateVerify. This is a fairly heavily important extension. > > I'd be in favor of this. Wouldn't switching OCSP stapling from "extension" to "proper part of the TLS 1.3 messages" mess things up for the TLS Feature certificate extension [1], which can be used to tell a TLS client that it should expect to receive TLS extension 5 (status_request) and/or TLS extension 17 (status_request_v2) from the TLS server? [1] https://tools.ietf.org/html/rfc7633 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Dec 14 04:49:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE2E1ACE09 for ; Mon, 14 Dec 2015 04:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-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 dAfD5Kx24k_s for ; Mon, 14 Dec 2015 04:49:50 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8E2F1A6F8C for ; Mon, 14 Dec 2015 04:49:50 -0800 (PST) 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 (Postfix) with ESMTPS id 7399EC0B930A; Mon, 14 Dec 2015 12:49:50 +0000 (UTC) Received: from dhcp-10-40-3-124.brq.redhat.com (dhcp-10-40-3-124.brq.redhat.com [10.40.3.124]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBECnm0U030730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Dec 2015 07:49:49 -0500 Message-ID: <1450097387.3786.53.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "Salz, Rich" , "tls@ietf.org" Date: Mon, 14 Dec 2015 13:49:47 +0100 In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-Tqiz1KvvoyfJh3lyRZdw" Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Subject: Re: [TLS] chacha/poly interop? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Dec 2015 12:49:52 -0000 --=-Tqiz1KvvoyfJh3lyRZdw Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Thu, 2015-12-10 at 01:02 +0000, Salz, Rich wrote: > OpenSSL just landed our chacha/poly implementation into master.  We > pass the RFC test vectors, looking for other implementations to test > against.  Thanks. It seems to interoperate with gnutls' implementation. regards, Nikos --=-Tqiz1KvvoyfJh3lyRZdw Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit
On Thu, 2015-12-10 at 01:02 +0000, Salz, Rich wrote:

OpenSSL just landed our chacha/poly implementation into master.  We pass the RFC test vectors, looking for other implementations to test against.  Thanks.


It seems to interoperate with gnutls' implementation.

regards,
Nikos

--=-Tqiz1KvvoyfJh3lyRZdw-- From nobody Mon Dec 14 05:23:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CA81ACE65 for ; Mon, 14 Dec 2015 05:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 370COeLbj6Ud for ; Mon, 14 Dec 2015 05:23:41 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0040B1ACE63 for ; Mon, 14 Dec 2015 05:23:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 37243660; Mon, 14 Dec 2015 15:23:38 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id 7iOle31JN5pC; Mon, 14 Dec 2015 15:23:37 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id E41AE1E0; Mon, 14 Dec 2015 15:23:37 +0200 (EET) Date: Mon, 14 Dec 2015 15:23:34 +0200 From: Ilari Liusvaara To: Rob Stradling Message-ID: <20151214132334.GA22971@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151211185258.GA5451@LK-Perkele-V2.elisa-laajakaista.fi> <2cef9d92f1e344f09053fc4efbe2c381@usma1ex-dag1mb1.msg.corp.akamai.com> <566EB625.7060402@comodo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <566EB625.7060402@comodo.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 and OCSP stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Dec 2015 13:23:43 -0000 On Mon, Dec 14, 2015 at 12:29:25PM +0000, Rob Stradling wrote: > On 12/12/15 15:02, Salz, Rich wrote: > >>I think that the best way to deal with the status_request_v2 extension is to > >>make it a proper part of the TLS 1.3 messages, probably Certificate or > >>CertificateVerify. This is a fairly heavily important extension. > > > >I'd be in favor of this. > > Wouldn't switching OCSP stapling from "extension" to "proper part of the TLS > 1.3 messages" mess things up for the TLS Feature certificate extension [1], > which can be used to tell a TLS client that it should expect to receive TLS > extension 5 (status_request) and/or TLS extension 17 (status_request_v2) > from the TLS server? If one needed to, one could make up rules with regards to extension negotiation. Also, this is just the message, not the extension, so one probably does not have to. Rule that if status_request_v2 is missing, then status_request_v2 with single item with blank responder id list and blank extension is impiled would prbably go bit too far. Or that TLS 1.3 always implicitly ACKs status_request_v2[1]... TLS Extensions 5 (status_request) and 9 (cert_type) are a bit special, as both have essentially been superceded by other extensions that can perform everything those extensions can and more. Also, for some reason status_request is marked as deprecated in TLS 1.3 (status_request_v2 is still there). [1] Considering extended_master_secret always negotiatied in TLS 1.3 might be a good idea, for backward compatiblity with software that checks for EMS as check for "not vulernable to THS". -Ilari From nobody Mon Dec 14 09:43:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439A91ACE8D for ; Mon, 14 Dec 2015 09:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ZYWAdCOSchVK for ; Mon, 14 Dec 2015 09:43:32 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id BEA061ACE81 for ; Mon, 14 Dec 2015 09:43:32 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 18DAD425CBB; Mon, 14 Dec 2015 17:43:32 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 00BA3425C99; Mon, 14 Dec 2015 17:43:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1450115012; bh=L52vw2FjKksvVP/hoIM4QlCrLoE0L5WlCqp9MsMG63A=; l=1302; h=To:References:From:Date:In-Reply-To:From; b=lU+oYy2dSOylPM6mq2TW2K8QrCKyCA6GzsIf3QKXLADQEAauyR6Ruz/ttR6l3YpQk +bPMQuVjobUdoIEOXWIOwW89PtGzUimz5YKX1XiqFrtnJDeUiSP6CPpSgfjwj9Tbd9 b4ld+exU5ew5/l/TapGcyJSOVKK34u74Bn+9hM0I= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id BFAD42039; Mon, 14 Dec 2015 17:43:31 +0000 (GMT) To: Bryan A Ford , "tls@ietf.org" References: <566BF6F4.7050100@gmail.com> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <566EFFC3.1090400@akamai.com> Date: Mon, 14 Dec 2015 11:43:31 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <566BF6F4.7050100@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Prototype of TLS 1.3 records, padding, and optional headerless records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Dec 2015 17:43:35 -0000 On 12/12/2015 04:29 AM, Bryan A Ford wrote: > --- > OK, congratulations and thanks to anyone who persisted through all that. > I hope this will help understand the implementation complexity and > tradeoffs both of the currently-specified TLS 1.3 record layer and the > proposed headerless records features. Comments? > This makes me less uneasy than the previous proposals did. As a general note, a protocol having two (or more) options for how to express a given piece of information leads to more cases to test, and has caused interoperability and/or security problems in the past. No comment from me yet as to whether the tradeoff is acceptable in this case. But, my general sentiment remains one that I did not get to express in the previous thread (I was travelling and it had become somewhat stale): will attempting to add this to TLS 1.3 incur unacceptable delay for wide-scale deployment? TLS 1.3 has a lot of really nice things in it, that we would like to get to users as soon as safely possible. There is the TRON workshop scheduled, etc., indicating that if all goes well, the spec could be final in the next 6 months. Is the added value of this scheme worth another month of delay before TLS 1.3 ships to users while we argue about it? Another six months? -Ben From nobody Tue Dec 15 13:15:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2121ACE49 for ; Tue, 15 Dec 2015 13:15:11 -0800 (PST) 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, HTML_MESSAGE=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 g40D50Td6RVH for ; Tue, 15 Dec 2015 13:15:10 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 851E31ACE69 for ; Tue, 15 Dec 2015 13:15:10 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id k189so34487272qkc.0 for ; Tue, 15 Dec 2015 13:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type; bh=VUYsUn5XPtisTxSAJuneo4apWxYRRwvgxsUTDU6NM7E=; b=APxqZC6Fc2wbVyw20EiXkdFpoQH37cNCoVjiafsIPhCBvnC4vytbpyaCEHPba+Y8OW 1RhvlqJUwmgBQHweebcXV1eli/zB5rbOVHoaBSE2yu4oqjooFSSWzsXdjksIVBftlyUT j3AXDJjgVjrqABfPh61aGhmlpjKmg5FSA+WbI/qzPvLOTb3ZDuENd3DmvBlxn/xHzbff Za3DhIpusHRml0DZ7QKlC9RihK122gmHjCrCzQAnJcUNtXI1WpQuuHZjWZzRuO/TRCI0 RUmyGHv/ycCVDdY4jqo7mJlwkWVdaIJyEhaBjfOB+BtS1w8Um5c7/hZsNCF9s/9vKXTB KYBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=VUYsUn5XPtisTxSAJuneo4apWxYRRwvgxsUTDU6NM7E=; b=LhWBh3FWuSoY5Bvfolt7kw1vfUUUDOc8SVTFCgyi3PaM9liEJ0m2GJzrE9n6F9XHwH NGdAzir9iGCBSlAUz1M9S8gVYbdHcJhdhs6VmMoMyqSwX+b5Z3g1Mwk+Y0+PNHgtDnus MKGp/KYpZRPaTwj8bn2Qzzj84CywZ7tGOmIzb+17F5GjvBlvj+Mko1ejgoItfAEwA+xM CnrdcgP4eyLmm/MX2gpdM97SUYvELrEyAeY0G0pAY//85k0dI33R1zARZwwOvoPUJ1Nb AC0Y+Cq9y8tXvlGhDfrIhoga6Vx2dbDe1D5L2oKwo3JB/UrFXl28EZn36RdXvBZB+deY T+xA== X-Gm-Message-State: ALoCoQk006qrwFvEPbCuRcsN0EyP8zA1UCtc/b1qHHgT5r7E5dByxjzZzu/8/Sqm+z1skA3UnD0O95CQELqxrIWahLyIGdD0+A== X-Received: by 10.129.148.3 with SMTP id l3mr24731953ywg.155.1450214109611; Tue, 15 Dec 2015 13:15:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 15 Dec 2015 13:14:30 -0800 (PST) From: Eric Rescorla Date: Tue, 15 Dec 2015 13:14:30 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c07c8bcda333a0526f648f9 Archived-At: Subject: [TLS] Data volume 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: Tue, 15 Dec 2015 21:15:11 -0000 --94eb2c07c8bcda333a0526f648f9 Content-Type: text/plain; charset=UTF-8 Watson kindly prepared some text that described the limits on what's safe for AES-GCM and restricting all algorithms with TLS 1.3 to that lower limit (2^{36} bytes), even though ChaCha doesn't have the same restriction. I wanted to get people's opinions on whether that's actually what we want or whether we should (as is my instinct) allow people to use ChaCha for longer periods. -Ekr --94eb2c07c8bcda333a0526f648f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Watson kindly prepared some text that described the limits= on what's safe
for AES-GCM and restricting all algorithms with TLS= 1.3 to that lower
limit (2^{36} bytes), even though ChaCha doesn= 't have the same
restriction.

I want= ed to get people's opinions on whether that's actually what we want=
or whether we should (as is my instinct) allow people to use Cha= Cha
for longer periods.

-Ekr
<= br>
--94eb2c07c8bcda333a0526f648f9-- From nobody Tue Dec 15 13:16:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33D11ACE70 for ; Tue, 15 Dec 2015 13:16:14 -0800 (PST) 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, HTML_MESSAGE=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 kCi2OezFx3c2 for ; Tue, 15 Dec 2015 13:16:14 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DCF1ACE6E for ; Tue, 15 Dec 2015 13:16:13 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id k189so34531765qkc.0 for ; Tue, 15 Dec 2015 13:16:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=feeOhk/FvSRcV8uv8bIl75sIWfV1CeBc2hYMCQaVzrk=; b=rqTwYrwijraXvAenmF6oN7CQOXySK0OY4Rd+cwrKSl4iq+Qbd0CIhCohNbasNCI8O2 f/FXNgE4zs6VbkHx+lTVDggwMkte69BQT0W2gN0jcp1tmtXvUXRqqKoHfa5Zx1oE/UHC N4ZPLg4LW5UBS0iqQdCzsierqqwblbv0NPsuGhJ0ugwmrZXYArLyC7zYOX6KtHWAE1xT 8B6rF+Vm87E7/yYstqK/Ee9JTuvCYQNla4N8ry+EVe5DYOiPBwfQJHhzI3qNI7agkY3w WwAUb8LM3/hpr0mPzXjQJ6RelXDNqvGzkq5eBpQYCApbvvHGgOZEa9Soj/3q+283VGC3 /zGw== 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:content-type; bh=feeOhk/FvSRcV8uv8bIl75sIWfV1CeBc2hYMCQaVzrk=; b=I4gK9RVpeYg27Kgxz47dvTCZC11DmizDTv2s/9Qu8CXvAAgZMYw/1uC6yQLgtuWzN9 XeI0/sCfcvQy2pWlW+lo0GEbVaGWLCs6IuMktyx4qNgqyFsYy+KPIDcfdop8+qw6TF/V hf/PVlbsYt7DsyNmd5T9XxeRvGcVTSYygUzJzdgKd1Sg79cDm74MhHRkpwg/CKISSxcQ rvG7vUy8I9LVJ+C0kGmbEHOm3xx+/ueQf9Bc0MQyfxUkk5ndxuzVzETxdygVmJCGgxVW +oNwpeUrNQBwnVOqdvnQ9Cjutf7gBiHXU7FiJPzHkxb/wqGUi5AjTLk18d3ZYs8tpVpd O/dg== X-Gm-Message-State: ALoCoQmTCYlbfRk67I+QWSBUk/TFcCAtDTxKuVyClYRyE8fUIHQ/meGENCsdg3Pi81mOEhyNRjiNt0f71xBba58HwcNgclffuQ== X-Received: by 10.129.79.87 with SMTP id d84mr16917132ywb.115.1450214172988; Tue, 15 Dec 2015 13:16:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 15 Dec 2015 13:15:33 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 15 Dec 2015 13:15:33 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114dc360a1464e0526f64cdf Archived-At: Subject: Re: [TLS] Data volume 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: Tue, 15 Dec 2015 21:16:15 -0000 --001a114dc360a1464e0526f64cdf Content-Type: text/plain; charset=UTF-8 For context, see: https://github.com/tlswg/tls13-spec/pull/372 On Tue, Dec 15, 2015 at 1:14 PM, Eric Rescorla wrote: > Watson kindly prepared some text that described the limits on what's safe > for AES-GCM and restricting all algorithms with TLS 1.3 to that lower > limit (2^{36} bytes), even though ChaCha doesn't have the same > restriction. > > I wanted to get people's opinions on whether that's actually what we want > or whether we should (as is my instinct) allow people to use ChaCha > for longer periods. > > -Ekr > > --001a114dc360a1464e0526f64cdf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For context, see:

On Tue,= Dec 15, 2015 at 1:14 PM, Eric Rescorla <ekr@rtfm.com> wrote:
=
Watson kindly prepared some= text that described the limits on what's safe
for AES-GCM and rest= ricting all algorithms with TLS 1.3 to that lower
limit (2^{36} b= ytes), even though ChaCha doesn't have the same
restriction.<= /div>

I wanted to get people's opinions on whether t= hat's actually what we want
or whether we should (as is my in= stinct) allow people to use ChaCha
for longer periods.
=
-Ekr


--001a114dc360a1464e0526f64cdf-- From nobody Tue Dec 15 13:17:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862121ACE65 for ; Tue, 15 Dec 2015 13:17:48 -0800 (PST) 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 yX1O7_86dOOv for ; Tue, 15 Dec 2015 13:17:47 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B023C1ACE88 for ; Tue, 15 Dec 2015 13:17:35 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id p187so34451202qkd.1 for ; Tue, 15 Dec 2015 13:17:35 -0800 (PST) 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=jxyiGxK/XJeUCLN301MxUbl5+cQ+Kp7wrM+AhKAQEcs=; b=KHzdttRU5SQ/pjgjrpy7tkr1qWve/rUb1W91FgrQL4KKPHQaU/1QY/LMh99JOiT/Vm HChX4NCXO0BWlRzPkOYAajGNCR/eMWtrFy/HdFYUjnGcONHE0oKqS8H+IXOj1N/Fkbke 2hYru6AH3G+WTvqYT4c7evbLlNOGjps+0/C2intQYtN8xhkhlWaG6e711SkGjsuQsiuo i/rppXCmpHtAIVCGifhrAxzm5rztGsRaKeh3kC/Nx/PQ3wKXKJGMlWn3Lo1gplO6F70Z jsOUpBjWDw0P+lv+DEZGnNo6lknWr8IBHMgNu8xz95PuoIcx600dXndnMC4FbRovaKXS /8qA== MIME-Version: 1.0 X-Received: by 10.129.57.135 with SMTP id g129mr24093162ywa.244.1450214254870; Tue, 15 Dec 2015 13:17:34 -0800 (PST) Received: by 10.129.148.131 with HTTP; Tue, 15 Dec 2015 13:17:34 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Dec 2015 16:17:34 -0500 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Tue, 15 Dec 2015 21:17:48 -0000 I don't think that's what I intended: I think the limit should be ciphersuite specific. Unfortunately that requires more work. On Tue, Dec 15, 2015 at 4:15 PM, Eric Rescorla wrote: > For context, see: > https://github.com/tlswg/tls13-spec/pull/372 > > On Tue, Dec 15, 2015 at 1:14 PM, Eric Rescorla wrote: >> >> Watson kindly prepared some text that described the limits on what's safe >> for AES-GCM and restricting all algorithms with TLS 1.3 to that lower >> limit (2^{36} bytes), even though ChaCha doesn't have the same >> restriction. >> >> I wanted to get people's opinions on whether that's actually what we want >> or whether we should (as is my instinct) allow people to use ChaCha >> for longer periods. >> >> -Ekr >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Dec 15 13:19:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A957F1ACE7C for ; Tue, 15 Dec 2015 13:19:24 -0800 (PST) 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, HTML_MESSAGE=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 NHfRMHAocs8T for ; Tue, 15 Dec 2015 13:19:23 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685891ACE57 for ; Tue, 15 Dec 2015 13:19:23 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id p187so34525213qkd.1 for ; Tue, 15 Dec 2015 13:19:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5Qdxctim1OJ1FL9IL11yokZJLM9kjO71gxI/fbrifpY=; b=RLHS/fnjuTuJVLiFNXK8MEcpvV5+MQ4Am+I5kglfmDJjJloJpK6vc0AmUny7/MgBD6 /w4RnuNV1XXbcpZwRXzCgZZmHEkXuN+6ewiMEnABfABW/JDNIIA7UHxlX4suEjUghDxt LCjUbJNYwQsILsWXg3VbJs2MbjuP7Ll9oUBHuAsZsSkoKNfyRC3jGxP4LfGQiFflF7Fx 3wqLdpEHOkzlghkW4qybUImqTUmANQvU1lUZEbuLrbvrZKjna7HBAFlqGauLDWRgv1s1 WNyuOfsAxAtm95zYN1XJrArlWynJ9bGGjSap4w7hPLP9S867nmTjskkn5z2BI4IXJe0H 93ZA== 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=5Qdxctim1OJ1FL9IL11yokZJLM9kjO71gxI/fbrifpY=; b=RAAiGXNWqeSxfI955UJJLhkjwcsHSBhG2fXmX9nELMO2kUolPntM7kb20g0J7ssuEJ RP9FNWOBle5pXOqsuQcZguBQTUOdRAGxt5gn/ne7Xvrjj1G3URbGZw0dTPKFwH2mRKh0 jmeObOmE3vb5Y8LlaDbeePFdlNTC4YXh2bCUdQecDJdpZ2ibwDtu6eD418RzPCG2gVPB ALIjddwm9u8pVjia2ScuukTuv/gqxQqm548BBybwAk8+FyBjsTw4nwJwu7yPSYTAVBbq 7H9uXGU1bWC6l3TlOTrzBR1OTEce28lNV4fb3rT0cSugx++gxOvn8ePeynM4lkQfe40c i5bQ== X-Gm-Message-State: ALoCoQnH4D0IPRwV9rVfdgn3IpP3F6WaKIV+TzxLSV7f2o23pbU+Po0BtORRorXRSA56OxaXs2MTUK+AKitneymCd6GaN7M+/g== X-Received: by 10.129.46.84 with SMTP id u81mr24510310ywu.129.1450214362622; Tue, 15 Dec 2015 13:19:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 15 Dec 2015 13:18:43 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 15 Dec 2015 13:18:43 -0800 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a11409380eee0870526f657ca Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Tue, 15 Dec 2015 21:19:24 -0000 --001a11409380eee0870526f657ca Content-Type: text/plain; charset=UTF-8 On Tue, Dec 15, 2015 at 1:17 PM, Watson Ladd wrote: > I don't think that's what I intended: I think the limit should be > ciphersuite specific. Unfortunately that requires more work. > That makes sense. Do you think you'll be able to provide that in the not too distant future? I can just leave this on ice till then... -Ekr > On Tue, Dec 15, 2015 at 4:15 PM, Eric Rescorla wrote: > > For context, see: > > https://github.com/tlswg/tls13-spec/pull/372 > > > > On Tue, Dec 15, 2015 at 1:14 PM, Eric Rescorla wrote: > >> > >> Watson kindly prepared some text that described the limits on what's > safe > >> for AES-GCM and restricting all algorithms with TLS 1.3 to that lower > >> limit (2^{36} bytes), even though ChaCha doesn't have the same > >> restriction. > >> > >> I wanted to get people's opinions on whether that's actually what we > want > >> or whether we should (as is my instinct) allow people to use ChaCha > >> for longer periods. > >> > >> -Ekr > >> > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > --001a11409380eee0870526f657ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 15, 2015 at 1:17 PM, Watson Ladd <watsonbladd@gmail.co= m> wrote:
I don't think= that's what I intended: I think the limit should be
ciphersuite specific. Unfortunately that requires more work.

That makes sense. Do you think you'll be able to = provide that in the not
too distant future? I can just leave this= on ice till then...

-Ekr


On Tue, Dec 15, 2015 at 4:15 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> For context, see:
> https://github.com/tlswg/tls13-spec/pull/372 >
> On Tue, Dec 15, 2015 at 1:14 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> Watson kindly prepared some text that described the limits on what= 's safe
>> for AES-GCM and restricting all algorithms with TLS 1.3 to that lo= wer
>> limit (2^{36} bytes), even though ChaCha doesn't have the same=
>> restriction.
>>
>> I wanted to get people's opinions on whether that's actual= ly what we want
>> or whether we should (as is my instinct) allow people to use ChaCh= a
>> for longer periods.
>>
>> -Ekr
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



--
"Man is born free, but everywhere he is in chains".
--Rousseau.

--001a11409380eee0870526f657ca-- From nobody Tue Dec 15 13:25:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BC01ACDD5 for ; Tue, 15 Dec 2015 13:25:53 -0800 (PST) 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 EnwFthZCWFd9 for ; Tue, 15 Dec 2015 13:25:51 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D986B1ACE9A for ; Tue, 15 Dec 2015 13:25:48 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id t125so34744450qkh.3 for ; Tue, 15 Dec 2015 13:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=wKua8VQc+ZP11aiGIti7K27kOUZR4TAZ9RWwuTTInDI=; b=vq6bcb1rW2OQQk17ouuHX6BYSmPpYWhcVou6Casjvthah0HcEwv4Zhxeg01bXHr5Tr z0avjVPQxDeyqqkFt+d/I28DNop2jwcPbqs6KUNK9s76k3KXCxRTGYil1lzPd7+66utz c9BKtyPn/kFExmjjebNviZcQ28tfM+Cy48/l0CUAo2jLCDWCGEFPJoND+0FAEhUX+Mut IKI0ANNQvK1doh96MMPpWHbFnD4SWvt0ZSahYPLtIUzQEJZFQdpfgmw5iywcsOcE/vgp eeMHCQOvINKRhA7u7kQHraKCD7yiC3N5iqOvzRJsc18sQVAJ4KEPc6990qUSbNvWDaFK YzYQ== X-Received: by 10.55.80.68 with SMTP id e65mr56002453qkb.46.1450214748060; Tue, 15 Dec 2015 13:25:48 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id z19sm1294539qge.18.2015.12.15.13.25.47 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 15 Dec 2015 13:25:47 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Tue, 15 Dec 2015 16:25:46 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201512151625.46662.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Data volume 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: Tue, 15 Dec 2015 21:25:53 -0000 Personally, I think a hard requirement to rekey every 64GiB is reasonable enough to just use it for every cipher. I don't think cipher-specific requirements are worth the effort/complexity. Something like a MUST for AES-GCM and a SHOULD for ChaCha seems fine, though, if really desired. Dave On Tuesday, December 15, 2015 04:17:34 pm Watson Ladd wrote: > I don't think that's what I intended: I think the limit should be > ciphersuite specific. Unfortunately that requires more work. > > On Tue, Dec 15, 2015 at 4:15 PM, Eric Rescorla wrote: > > For context, see: > > https://github.com/tlswg/tls13-spec/pull/372 > > > > On Tue, Dec 15, 2015 at 1:14 PM, Eric Rescorla wrote: > >> > >> Watson kindly prepared some text that described the limits on what's safe > >> for AES-GCM and restricting all algorithms with TLS 1.3 to that lower > >> limit (2^{36} bytes), even though ChaCha doesn't have the same > >> restriction. > >> > >> I wanted to get people's opinions on whether that's actually what we want > >> or whether we should (as is my instinct) allow people to use ChaCha > >> for longer periods. > >> > >> -Ekr From nobody Tue Dec 15 13:27:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368261A8777 for ; Tue, 15 Dec 2015 13:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 f4C5An1ipzOe for ; Tue, 15 Dec 2015 13:27:11 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 103A81ACE80 for ; Tue, 15 Dec 2015 13:27:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.20,434,1444687200"; d="scan'208";a="192324079" Received: from ram75-1-78-192-222-230.fbxo.proxad.net (HELO [192.168.1.30]) ([78.192.222.230]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Dec 2015 22:27:09 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Benjamin Beurdouche In-Reply-To: Date: Tue, 15 Dec 2015 22:27:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Watson Ladd , Eric Rescorla , Dave Garrett X-Mailer: Apple Mail (2.3112) Archived-At: Cc: ML IETF TLS Subject: Re: [TLS] Data volume 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: Tue, 15 Dec 2015 21:27:13 -0000 > On 15 Dec 2015, at 22:17, Watson Ladd wrote: >=20 > I don't think that's what I intended: I think the limit should be > ciphersuite specific. Unfortunately that requires more work. >=20 > On Tue, Dec 15, 2015 at 4:15 PM, Eric Rescorla wrote: >>=20 >>> I wanted to get people's opinions on whether that's actually what we = want >>> or whether we should (as is my instinct) allow people to use ChaCha >>> for longer periods. IMHO, if we differentiate the limit depending on the ciphersuite, it = will be more complex to handle and cause problems at some point. I would rather have a single value in the spec that is safe for all = allowed ciphersuites, rekey more frequently and leave people take their = own risks by setting higher limits if they do not negotiate AES-GCM (for = example). B.= From nobody Tue Dec 15 14:01:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423071B2B58 for ; Tue, 15 Dec 2015 14:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, 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 d7-xJMztr88J for ; Tue, 15 Dec 2015 14:01:55 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4641B2B50 for ; Tue, 15 Dec 2015 14:01:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9368; q=dns/txt; s=iport; t=1450216915; x=1451426515; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=t32nTBGgUAFIvVeFZOkngyqavOkydO86GYtHi0xSKpg=; b=acU1S2NrC6XNftKcPk871preFl6tUqkxRJE7O3F8vG9XSxKL3ZLzFwk/ 5gpXMV6DLcZAfOwLlc2EgU16vnM016GwTzbWuD81zVmhujkp23iILQbRo T+2j5+IUdw84vIQs7jAUt5Z8OZG+1T4Dk6EAgBiFg5LFno3RytfyKTERn 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgD9jHBW/4YNJK1egm5MUm0GvVMBD?= =?us-ascii?q?YFjhg0CHIEuOBQBAQEBAQEBgQqENAEBAQQjClwCAQgOAwQBASgDAgICMBQJCAI?= =?us-ascii?q?EARIIiCereZF0AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZWhH2EKwpcgmaBSQWIM?= =?us-ascii?q?4pTg3YBjUCdIAEfAQFCgg4ggVZygypCgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,434,1444694400"; d="scan'208,217";a="217057116" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Dec 2015 22:01:54 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id tBFM1rDV028973 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Dec 2015 22:01:54 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Dec 2015 17:01:53 -0500 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1104.009; Tue, 15 Dec 2015 17:01:53 -0500 From: "Scott Fluhrer (sfluhrer)" To: Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] Data volume limits Thread-Index: AQHRN321+GNchELNkkOmU2Gwkrt9SJ7MlZaA Date: Tue, 15 Dec 2015 22:01:52 +0000 Message-ID: References: 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: [10.98.2.55] Content-Type: multipart/alternative; boundary="_000_e007baa2f53249d49917e6023e578bc0XCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Data volume 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: Tue, 15 Dec 2015 22:01:57 -0000 --_000_e007baa2f53249d49917e6023e578bc0XCHRTP006ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWlnaHQgSSBlbnF1aXJlIGFib3V0IHRoZSBjcnlwdG9ncmFwaGljYWwgcmVhc29uIGJlaGluZCBz dWNoIGEgbGltaXQ/DQoNCklzIHRoaXMgdGhlIGxpbWl0IG9uIHRoZSBzaXplIG9mIGEgc2luZ2xl IHJlY29yZD8gIEdDTSBkb2VzIGhhdmUgYSBsaW1pdCBhcHByb3hpbWF0ZWx5IHRoZXJlIG9uIHRo ZSBzaXplIG9mIGEgc2luZ2xlIHBsYWludGV4dCBpdCBjYW4gZW5jcnlwdC4gIEZvciBUTFMsIGl0 IGVuY3J5cHRzIGEgcmVjb3JkIGFzIGEgc2luZ2xlIHBsYWludGV4dCwgYW5kIHNvIHRoaXMgd291 bGQgYXBwbHkgdG8gZXh0cmVtZWx5IGh1Z2UgcmVjb3Jkcy4NCg0KT3IgaXMgdGhpcyBhIGxpbWl0 IG9uIHRoZSB0b3RhbCBhbW91bnQgb2YgdHJhZmZpYyB0aGF0IGNhbiBnbyB0aHJvdWdoIGEgY29u bmVjdGlvbiBvdmVyIG11bHRpcGxlIHJlY29yZHM/ICBJZiB0aGlzIGlzIHRoZSBpc3N1ZSwgd2hh dCBpcyB0aGUgc2VjdXJpdHkgY29uY2VybiB0aGF0IHlvdSB3b3VsZCBoYXZlIGlmIHRoYXQgbGlt aXQgaXMgZXhjZWVkZWQ/DQoNClRoYW5rIHlvdS4NCg0KRnJvbTogVExTIFttYWlsdG86dGxzLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50OiBUdWVzZGF5 LCBEZWNlbWJlciAxNSwgMjAxNSA0OjE1IFBNDQpUbzogdGxzQGlldGYub3JnDQpTdWJqZWN0OiBb VExTXSBEYXRhIHZvbHVtZSBsaW1pdHMNCg0KV2F0c29uIGtpbmRseSBwcmVwYXJlZCBzb21lIHRl eHQgdGhhdCBkZXNjcmliZWQgdGhlIGxpbWl0cyBvbiB3aGF0J3Mgc2FmZQ0KZm9yIEFFUy1HQ00g YW5kIHJlc3RyaWN0aW5nIGFsbCBhbGdvcml0aG1zIHdpdGggVExTIDEuMyB0byB0aGF0IGxvd2Vy DQpsaW1pdCAoMl57MzZ9IGJ5dGVzKSwgZXZlbiB0aG91Z2ggQ2hhQ2hhIGRvZXNuJ3QgaGF2ZSB0 aGUgc2FtZQ0KcmVzdHJpY3Rpb24uDQoNCkkgd2FudGVkIHRvIGdldCBwZW9wbGUncyBvcGluaW9u cyBvbiB3aGV0aGVyIHRoYXQncyBhY3R1YWxseSB3aGF0IHdlIHdhbnQNCm9yIHdoZXRoZXIgd2Ug c2hvdWxkIChhcyBpcyBteSBpbnN0aW5jdCkgYWxsb3cgcGVvcGxlIHRvIHVzZSBDaGFDaGENCmZv ciBsb25nZXIgcGVyaW9kcy4NCg0KLUVrcg0KDQo= --_000_e007baa2f53249d49917e6023e578bc0XCHRTP006ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5NaWdodCBJIGVucXVpcmUgYWJvdXQgdGhlIGNy eXB0b2dyYXBoaWNhbCByZWFzb24gYmVoaW5kIHN1Y2ggYSBsaW1pdD88bzpwPjwvbzpwPjwvc3Bh bj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPklzIHRo aXMgdGhlIGxpbWl0IG9uIHRoZSBzaXplIG9mIGEgc2luZ2xlIHJlY29yZD8mbmJzcDsgR0NNIGRv ZXMgaGF2ZSBhIGxpbWl0IGFwcHJveGltYXRlbHkgdGhlcmUgb24gdGhlIHNpemUgb2YgYSBzaW5n bGUgcGxhaW50ZXh0IGl0IGNhbiBlbmNyeXB0LiZuYnNwOyBGb3IgVExTLCBpdCBlbmNyeXB0cw0K IGEgcmVjb3JkIGFzIGEgc2luZ2xlIHBsYWludGV4dCwgYW5kIHNvIHRoaXMgd291bGQgYXBwbHkg dG8gZXh0cmVtZWx5IGh1Z2UgcmVjb3Jkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+T3IgaXMgdGhpcyBhIGxpbWl0IG9uIHRo ZSB0b3RhbCBhbW91bnQgb2YgdHJhZmZpYyB0aGF0IGNhbiBnbyB0aHJvdWdoIGEgY29ubmVjdGlv biBvdmVyIG11bHRpcGxlIHJlY29yZHM/Jm5ic3A7IElmIHRoaXMgaXMgdGhlIGlzc3VlLCB3aGF0 IGlzIHRoZSBzZWN1cml0eSBjb25jZXJuDQogdGhhdCB5b3Ugd291bGQgaGF2ZSBpZiB0aGF0IGxp bWl0IGlzIGV4Y2VlZGVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFuayB5b3UuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gVHVl c2RheSwgRGVjZW1iZXIgMTUsIDIwMTUgNDoxNSBQTTxicj4NCjxiPlRvOjwvYj4gdGxzQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtUTFNdIERhdGEgdm9sdW1lIGxpbWl0czxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XYXRzb24ga2lu ZGx5IHByZXBhcmVkIHNvbWUgdGV4dCB0aGF0IGRlc2NyaWJlZCB0aGUgbGltaXRzIG9uIHdoYXQn cyBzYWZlPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Zm9yIEFF Uy1HQ00gYW5kIHJlc3RyaWN0aW5nIGFsbCBhbGdvcml0aG1zIHdpdGggVExTIDEuMyB0byB0aGF0 IGxvd2VyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5saW1pdCAoMl57MzZ9IGJ5dGVzKSwgZXZlbiB0aG91Z2ggQ2hhQ2hhIGRvZXNuJ3QgaGF2ZSB0 aGUgc2FtZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+cmVzdHJpY3Rpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgd2FudGVkIHRvIGdldCBwZW9wbGUncyBvcGluaW9ucyBvbiB3aGV0aGVy IHRoYXQncyBhY3R1YWxseSB3aGF0IHdlIHdhbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9yIHdoZXRoZXIgd2Ugc2hvdWxkIChhcyBpcyBteSBp bnN0aW5jdCkgYWxsb3cgcGVvcGxlIHRvIHVzZSBDaGFDaGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZvciBsb25nZXIgcGVyaW9kcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_e007baa2f53249d49917e6023e578bc0XCHRTP006ciscocom_-- From nobody Tue Dec 15 14:08:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AACB1B2B9D for ; Tue, 15 Dec 2015 14:08:45 -0800 (PST) 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, HTML_MESSAGE=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 0UpfB9uajJSu for ; Tue, 15 Dec 2015 14:08:44 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25EED1B2B94 for ; Tue, 15 Dec 2015 14:08:43 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id t125so36441690qkh.3 for ; Tue, 15 Dec 2015 14:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PIL+FjZXHOuhIEy6mCEUEZZVBQI2rsxUMUXnWY+1Ivc=; b=O2aDRZGnjewpP9cA0vbVsgj4jIE3DttcryQx3H68Vl9I+5BVXpHPbzpCRoY95wmNnV tF4LOwGFpajRmiAiDtIePO/5cyUXsEGTYhXT2FfedD1tjUMDPJrzMY7EznoYEcVzq+GS HmUZoFhwNSc1jM95LEhHXOOb2jjvhQzCZ8nMNSIfTkhlwlRGRgn8WAH32vG8orxeRbNA +vDF2W02C5gSU2ldRsL11hWcDmEskV3ODWO34iE96T5FJA9ZOatfF4+dZPloVi1Mg3Tq Bt4Lh1+6PlZYiJOSp7thM/IP8ysmGob0BWpYGgBnrkDAdpneZYnDCx8u4MyF0IvQx5Ni KPWg== 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=PIL+FjZXHOuhIEy6mCEUEZZVBQI2rsxUMUXnWY+1Ivc=; b=XQiKe85woLL5dNvpRDAlw54ixOBes3hfT/pCPqLfNyRCM7SfQ+PoT0QfQLKvjZwXeI VsOBaU0jiOwV7PjvsqapWZ7vtPNDwWI1cLs92pzQBLxtkPt7cvUwc4V1B3mYxfL1nmAJ 4GdMb0O5awVtnO2cn39+nvc8zp7vHF1NlJizxbqiTM9OLbmXuz2SF9Jo7vqd9+jKlgHV ZQ/TeOC4z8Hor55P4YcpnVQkylVtLOMq5zAAasSvKnRkXDhb19JfaHSAB6ssJhYzgGrm AsnYNLW3l64xU/EEcJ5NbLdG6WzI7j66GKeko6mUC4iVbm6K4Av8r+07KgIcz2RPJhP0 nlhg== X-Gm-Message-State: ALoCoQmDYbMIQPP45PjcyylOiVTH3dK5aydYObBJnB1ul0SMZazzT10ugSvMeqwf1c/wtNLhhd2MSBEwAcWJ0SQSRp+JdhNWzA== X-Received: by 10.129.46.84 with SMTP id u81mr24650179ywu.129.1450217322310; Tue, 15 Dec 2015 14:08:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 15 Dec 2015 14:08:02 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 15 Dec 2015 14:08:02 -0800 Message-ID: To: "Scott Fluhrer (sfluhrer)" Content-Type: multipart/alternative; boundary=001a11409380581cbf0526f7087a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Tue, 15 Dec 2015 22:08:45 -0000 --001a11409380581cbf0526f7087a Content-Type: text/plain; charset=UTF-8 On Tue, Dec 15, 2015 at 2:01 PM, Scott Fluhrer (sfluhrer) < sfluhrer@cisco.com> wrote: > Might I enquire about the cryptographical reason behind such a limit? > > > > Is this the limit on the size of a single record? GCM does have a limit > approximately there on the size of a single plaintext it can encrypt. For > TLS, it encrypts a record as a single plaintext, and so this would apply to > extremely huge records. > > > > Or is this a limit on the total amount of traffic that can go through a > connection over multiple records? If this is the issue, what is the > security concern that you would have if that limit is exceeded? > Watson provided these, so perhaps he can elaborate. It would be good to have a value we all agree on. Thanks, -Ekr > > Thank you. > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Tuesday, December 15, 2015 4:15 PM > *To:* tls@ietf.org > *Subject:* [TLS] Data volume limits > > > > Watson kindly prepared some text that described the limits on what's safe > > for AES-GCM and restricting all algorithms with TLS 1.3 to that lower > > limit (2^{36} bytes), even though ChaCha doesn't have the same > > restriction. > > > > I wanted to get people's opinions on whether that's actually what we want > > or whether we should (as is my instinct) allow people to use ChaCha > > for longer periods. > > > > -Ekr > > > --001a11409380581cbf0526f7087a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 15, 2015 at 2:01 PM, Scott Fluhrer (sfluhrer) <= ;sfluhrer@cisco.com= > wrote:

Might I enquire about the cryptographical reason behind s= uch a limit?

=C2=A0=

Is this the limit on the si= ze of a single record?=C2=A0 GCM does have a limit approximately there on t= he size of a single plaintext it can encrypt.=C2=A0 For TLS, it encrypts a record as a single plaintext, and so this would apply to extremely huge = records.

=C2=A0=

Or is this a limit on the t= otal amount of traffic that can go through a connection over multiple recor= ds?=C2=A0 If this is the issue, what is the security concern that you would have if that limit is exceeded?


Watson provided these, so perhaps he can elabor= ate.

It would be good to have a value we all agree= on.

Thanks,
-Ekr


--001a11409380581cbf0526f7087a-- From nobody Tue Dec 15 14:18:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F92E1B2C15 for ; Tue, 15 Dec 2015 14:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PkNjT5HCM0di for ; Tue, 15 Dec 2015 14:18:47 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5611B2C13 for ; Tue, 15 Dec 2015 14:18:46 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id D41E09A403F; Tue, 15 Dec 2015 17:18:45 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id EkbTH8JAYpib; Tue, 15 Dec 2015 17:17:28 -0500 (EST) Received: from [192.168.2.104] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7F3269A401F; Tue, 15 Dec 2015 17:18:36 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Tue, 15 Dec 2015 17:18:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <454C3137-35AE-4D33-8E4B-2B60B766A0F7@vigilsec.com> References: To: Eric Rescorla X-Mailer: Apple Mail (2.1085) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Tue, 15 Dec 2015 22:18:48 -0000 On Dec 15, 2015, at 4:14 PM, Eric Rescorla wrote: > Watson kindly prepared some text that described the limits on what's = safe > for AES-GCM and restricting all algorithms with TLS 1.3 to that lower > limit (2^{36} bytes), even though ChaCha doesn't have the same > restriction. >=20 > I wanted to get people's opinions on whether that's actually what we = want > or whether we should (as is my instinct) allow people to use ChaCha > for longer periods. Perhaps the algorithm registration can provide the limit, allowing = implementations use the full period for each algorithm. Russ From nobody Tue Dec 15 14:28:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884531B2C33 for ; Tue, 15 Dec 2015 14:28:07 -0800 (PST) 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 LwCoBgcrDPiN for ; Tue, 15 Dec 2015 14:28:05 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5D61B2C2B for ; Tue, 15 Dec 2015 14:28:05 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id u65so18075544qkh.2 for ; Tue, 15 Dec 2015 14:28:05 -0800 (PST) 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=LWkjt88duPN9LQmqFdamVlOe0kZNPkTooFixK4p3/tY=; b=qgoX7L3R7hV+04DmTZQ98XU+bvPxrZoRwOFjlcYmyf6VJSWANnghENptYEMI/nBQPb dPO0atmdWPeMh1JbfuSO1QGFOO5834iCa6ILg23VSbX3MArG3Ts64ceOiwLFw3hT1maW Cd9x3UcCumUgZpAabYWsOqk1cZTwGnJxZikLTRjnZfQXyZ3VzTPEfgGsir0xDj0hLGxb AgQ4lVyZWZLjY/s8XrA44TpqWL9c3/bvfXmD5p9krnl7AZL57ZEzPvQaxMhkJ73XqBMG y4kwL6WiQhPcAwvCbalDBAczFp1nk0QpVa7P+dU5HHuPKcEr5HiGg3E1dJqQT9Kpr9vw vTcw== MIME-Version: 1.0 X-Received: by 10.129.125.193 with SMTP id y184mr24779357ywc.182.1450218484802; Tue, 15 Dec 2015 14:28:04 -0800 (PST) Received: by 10.129.148.131 with HTTP; Tue, 15 Dec 2015 14:28:04 -0800 (PST) In-Reply-To: <454C3137-35AE-4D33-8E4B-2B60B766A0F7@vigilsec.com> References: <454C3137-35AE-4D33-8E4B-2B60B766A0F7@vigilsec.com> Date: Tue, 15 Dec 2015 17:28:04 -0500 Message-ID: From: Watson Ladd To: Russ Housley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Tue, 15 Dec 2015 22:28:07 -0000 On Tue, Dec 15, 2015 at 5:18 PM, Russ Housley wrote: > > On Dec 15, 2015, at 4:14 PM, Eric Rescorla wrote: > >> Watson kindly prepared some text that described the limits on what's safe >> for AES-GCM and restricting all algorithms with TLS 1.3 to that lower >> limit (2^{36} bytes), even though ChaCha doesn't have the same >> restriction. >> >> I wanted to get people's opinions on whether that's actually what we want >> or whether we should (as is my instinct) allow people to use ChaCha >> for longer periods. > > Perhaps the algorithm registration can provide the limit, allowing implementations use the full period for each algorithm. That makes sense, but people might ignore these values in the registry, and the entries might not be reviewed as well as they should be compared to if they are in the relevant RFCs. > > Russ > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Dec 15 14:36:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35051B2C2A for ; Tue, 15 Dec 2015 14:36:24 -0800 (PST) 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_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 OmQ9fjvNxXIW for ; Tue, 15 Dec 2015 14:36:23 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6A961B2C23 for ; Tue, 15 Dec 2015 14:36:22 -0800 (PST) Received: from pc1 (0x3ec67ae7.inet.dsl.telianet.dk [::ffff:62.198.122.231]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Tue, 15 Dec 2015 23:36:19 +0100 id 0000000000000044.00000000567095E4.0000037F Date: Tue, 15 Dec 2015 23:36:39 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20151215233639.5a5e7558@pc1> In-Reply-To: References: X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.29; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-895-1450218980-0001-2" Archived-At: Subject: Re: [TLS] Data volume 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: Tue, 15 Dec 2015 22:36:24 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-895-1450218980-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 15 Dec 2015 13:14:30 -0800 Eric Rescorla wrote: > Watson kindly prepared some text that described the limits on what's > safe for AES-GCM and restricting all algorithms with TLS 1.3 to that > lower limit (2^{36} bytes), even though ChaCha doesn't have the same > restriction. >=20 > I wanted to get people's opinions on whether that's actually what we > want or whether we should (as is my instinct) allow people to use > ChaCha for longer periods. Let me state the opinion that unlikely will get adopted: Isn't that a good reason to reconsider whether GCM is a good mode in the first place? How about: Let's use chacha20, let's not set any limits because we don't have to, let's deprecate algorithms that can't keep up with that? (I generally think even TLS 1.3 deprecates a lot of stuff there is still far too much variation. Let's keep things simpler, let's reduce the algorithm zoo.) --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-895-1450218980-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWcJX3AAoJEKWIAHK7tR5CmqsP/2y3521UwmcfVy0zOCEfL1r/ QpC853tEqkPjOXSo2+HX/0ToXx90yglTsiRQLdtvjN4RQtJMNfO4KVgXQiEvzJqp 6XfOo6PjJ4DsalXrWOUR79sb1yoLbySji19g5cWUJlRTLo2rZS897F69Pkb2FvUY rk2D29DDGC27YeEhONksy1CcdEYoVQ8vD5g8BO3K48I6NXGEeVVOdhNEIPsGAvdw L17rsfgJ6q3DfUyOM/FCGECfvqLA0XmapQzgCxJUXiDjo3GCvrbtfjnuZi9/NRzp wPFULkRtGvxN6TEl50PXUqKtC9lO9F8mKkm8KUtNZLlrlHRk40Kog7p3bXzSEFqz /kIzTWjW4xOjRIBPhoe7zxJhGvbHzUSONloq+k9+cQTUTLHGo9YsvGm8l70p5csw g94AEQPZhX0c7it6Syby7ZcwEsBeXo9xeC8Iw9tTrWIFvdOMihbcz/yhO4S7f+dt 0HGNbzTdMELlFIBxuUZSluUuEEVB0cz5DK46uLF80wfXnyDYR0hx2nYMh/6OsM/O DndmwwJqtEABZ4NMbSeLHleGS9ymP7/gZZMhCdW0BULHL4RhMJ9AgTqHJMle2plj RBlxALPHtz6C5f2RD1ry/8m9DntqXlLSEsYL9IgRQ/HTOJEnVLJ0fuVW3wdncSEg 2X+LjgmqTVqysPozbrM/ =5fkd -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-895-1450218980-0001-2-- From nobody Tue Dec 15 14:38:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BDF1B2C2A for ; Tue, 15 Dec 2015 14:38:29 -0800 (PST) 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 P2PgezdMJWkq for ; Tue, 15 Dec 2015 14:38:27 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9DC1B2C5C for ; Tue, 15 Dec 2015 14:38:24 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id p187so37522241qkd.1 for ; Tue, 15 Dec 2015 14:38:24 -0800 (PST) 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=Sek8J60hwf30SSV6QHzTw/PDZ8lgogGUXsugdi+nVKw=; b=T3OZYqP9c+chDNrp1v1OpfxbMOns04lZtUnSNTd6+aHIf4Pbyt8P967p3nJVveqpU5 LUC2Mpufmlq1s0pg1oVQl7JxcGfg3r7E+KXJ2VCyYM7jzQS94DlRCmaSSzm0iB6PB07h Zp+aM4JvoSLSkmrtDLgsZfGsM4CKjyH2ysFMQfF90qZ6pSb3kDHcsJVIJPaMW+PzLjfp s7jtd17wHER0nV/qjtus+sjcIoecR2Gvct7tfYnXHQxX9aY7wBC3ffoy1MZV3ZXESnHD lRn6CoZCVupuMGwfIVVU6MlRCVaBLSn2YEqGVhnlF976UBe0SKcgFILqqSszQC0Rt0pv LQjA== MIME-Version: 1.0 X-Received: by 10.13.226.137 with SMTP id l131mr11551858ywe.239.1450219103311; Tue, 15 Dec 2015 14:38:23 -0800 (PST) Received: by 10.129.148.131 with HTTP; Tue, 15 Dec 2015 14:38:23 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Dec 2015 17:38:23 -0500 Message-ID: From: Watson Ladd To: "Scott Fluhrer (sfluhrer)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Tue, 15 Dec 2015 22:38:29 -0000 On Tue, Dec 15, 2015 at 5:01 PM, Scott Fluhrer (sfluhrer) wrote: > Might I enquire about the cryptographical reason behind such a limit? > > > > Is this the limit on the size of a single record? GCM does have a limit > approximately there on the size of a single plaintext it can encrypt. For > TLS, it encrypts a record as a single plaintext, and so this would apply to > extremely huge records. The issue is the bounds in Iwata-Ohashai-Minematsu's paper, which show a quadratic confidentiality loss after a total volume sent. This is an exploitable issue. > > > > Or is this a limit on the total amount of traffic that can go through a > connection over multiple records? If this is the issue, what is the > security concern that you would have if that limit is exceeded? > > > > Thank you. > > > > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla > Sent: Tuesday, December 15, 2015 4:15 PM > To: tls@ietf.org > Subject: [TLS] Data volume limits > > > > Watson kindly prepared some text that described the limits on what's safe > > for AES-GCM and restricting all algorithms with TLS 1.3 to that lower > > limit (2^{36} bytes), even though ChaCha doesn't have the same > > restriction. > > > > I wanted to get people's opinions on whether that's actually what we want > > or whether we should (as is my instinct) allow people to use ChaCha > > for longer periods. > > > > -Ekr > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Dec 15 14:41:19 2015 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7210F1B2C6D; Tue, 15 Dec 2015 14:41:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151215224116.10391.47585.idtracker@ietfa.amsl.com> Date: Tue, 15 Dec 2015 14:41:16 -0800 Archived-At: Cc: draft-ietf-tls-cached-info@ietf.org, tls-chairs@ietf.org, tls@ietf.org Subject: [TLS] Barry Leiba's No Objection on draft-ietf-tls-cached-info-20: (with COMMENT) 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: Tue, 15 Dec 2015 22:41:16 -0000 Barry Leiba has entered the following ballot position for draft-ietf-tls-cached-info-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have two comments about Section 8.2: 1. The Standards Action range starts at 0, and you've assigned 1 and 2, but not 0. Is it intended that 0 should remain reserved and unassigned? If so, you should say that. 2. For the Specification Required range, is there any guidance you can/should give to the designated expert? What do you expect the DE to look for when evaluating requests? Why might the DE not approve a request? From nobody Tue Dec 15 15:08:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8071B2C7B for ; Tue, 15 Dec 2015 15:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, 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 FYx3ijTAwRvr for ; Tue, 15 Dec 2015 15:08:19 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47FB91B2CC3 for ; Tue, 15 Dec 2015 15:08:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2296; q=dns/txt; s=iport; t=1450220899; x=1451430499; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XJLL1bzLwNTXf/egWfTvrAk/wgCuydPKGBfe2D62JHk=; b=bnm7D2NrCjXqrC73eHIU/zl82c4LrjRgQ7wP2zswj6LyhR4uFz4DakUG pdn5MYEOYQ1iyqr/lWxTo09HMzSv/h0F4g9ZUHsKa+dzQM7jvJoeWSp9Z PTL6NqnLQ5coegHP4Q5rsP6pOGaZjpedNfMrAjnZ52AKCM4rnRc5m+Bny k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgDonHBW/4QNJK1egzqBPwa9UwENg?= =?us-ascii?q?WOGDQIcgSQ4FAEBAQEBAQGBCoQ0AQEBBCMRRQwEAgEIEQQBAQECAiMDAgICHxE?= =?us-ascii?q?UAQgIAgQOBQiIEgMSq2iNRQ2EKgEBAQEBAQEBAQEBAQEBAQEBAQEBARiBAYVVh?= =?us-ascii?q?H2CU4Fig0KBSQWWfAGLT4FxlUaHWgEfAQFChARygypCgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,434,1444694400"; d="scan'208";a="59316305" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Dec 2015 23:08:18 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tBFN8IGj010634 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Dec 2015 23:08:18 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Dec 2015 18:08:17 -0500 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1104.009; Tue, 15 Dec 2015 18:08:17 -0500 From: "Scott Fluhrer (sfluhrer)" To: Watson Ladd Thread-Topic: [TLS] Data volume limits Thread-Index: AQHRN321+GNchELNkkOmU2Gwkrt9SJ7MlZaAgABh3ID//7FHcA== Date: Tue, 15 Dec 2015 23:08:17 +0000 Message-ID: <6674a4ec51fe4e158929bf429260d6ea@XCH-RTP-006.cisco.com> References: 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: [10.98.2.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Tue, 15 Dec 2015 23:08:22 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV2F0c29uIExhZGQgW21h aWx0bzp3YXRzb25ibGFkZEBnbWFpbC5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDE1 LCAyMDE1IDU6MzggUE0NCj4gVG86IFNjb3R0IEZsdWhyZXIgKHNmbHVocmVyKQ0KPiBDYzogRXJp YyBSZXNjb3JsYTsgdGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbVExTXSBEYXRhIHZvbHVt ZSBsaW1pdHMNCj4gDQo+IE9uIFR1ZSwgRGVjIDE1LCAyMDE1IGF0IDU6MDEgUE0sIFNjb3R0IEZs dWhyZXIgKHNmbHVocmVyKQ0KPiA8c2ZsdWhyZXJAY2lzY28uY29tPiB3cm90ZToNCj4gPiBNaWdo dCBJIGVucXVpcmUgYWJvdXQgdGhlIGNyeXB0b2dyYXBoaWNhbCByZWFzb24gYmVoaW5kIHN1Y2gg YSBsaW1pdD8NCj4gPg0KPiA+DQo+ID4NCj4gPiBJcyB0aGlzIHRoZSBsaW1pdCBvbiB0aGUgc2l6 ZSBvZiBhIHNpbmdsZSByZWNvcmQ/ICBHQ00gZG9lcyBoYXZlIGENCj4gPiBsaW1pdCBhcHByb3hp bWF0ZWx5IHRoZXJlIG9uIHRoZSBzaXplIG9mIGEgc2luZ2xlIHBsYWludGV4dCBpdCBjYW4NCj4g PiBlbmNyeXB0LiAgRm9yIFRMUywgaXQgZW5jcnlwdHMgYSByZWNvcmQgYXMgYSBzaW5nbGUgcGxh aW50ZXh0LCBhbmQgc28NCj4gPiB0aGlzIHdvdWxkIGFwcGx5IHRvIGV4dHJlbWVseSBodWdlIHJl Y29yZHMuDQo+IA0KPiBUaGUgaXNzdWUgaXMgdGhlIGJvdW5kcyBpbiBJd2F0YS1PaGFzaGFpLU1p bmVtYXRzdSdzIHBhcGVyLCB3aGljaCBzaG93IGENCj4gcXVhZHJhdGljIGNvbmZpZGVudGlhbGl0 eSBsb3NzIGFmdGVyIGEgdG90YWwgdm9sdW1lIHNlbnQuIFRoaXMgaXMgYW4gZXhwbG9pdGFibGUN Cj4gaXNzdWUuDQoNCkFjdHVhbGx5LCB0aGUgbWFpbiByZXN1bHQgb2YgdGhhdCBwYXBlciB3YXMg dGhhdCBHQ00gd2l0aCBub25jZXMgb3RoZXIgdGhhbiA5NiBiaXRzIHdlcmUgbGVzcyBzZWN1cmUg dGhhbiBwcmV2aW91cyB0aG91Z2h0IChvciwgcmF0aGVyLCB0aGF0IHRoZSBwcmV2aW91cyBwcm9v ZnMgd2VyZSB3cm9uZywgYW5kIHdoYXQgdGhleSBjYW4gcHJvdmUgaXMgY29uc2lkZXJhYmx5IHdv cnNlOyB3aGV0aGVyIHRoZWlyIHByb29mIGlzIHRpZ2h0IGlzIGFuIG9wZW4gcXVlc3Rpb24pLiAg VGhleSBhZGRyZXNzIDk2IGJpdCBub25jZXMgYXMgd2VsbCwgaG93ZXZlciB0aGUgcmVzdWx0cyB0 aGV5IGdldCBhcmUgZWZmZWN0aXZlbHkgdW5jaGFuZ2VkIGZyb20gdGhlIG9yaWdpbmFsIEdDTSBw YXBlci4gIEkgaGFkIHRob3VnaHQgdGhhdCBUTFMgdXNlZCA5NiBiaXQgbm9uY2VzIChjb25zdHJ1 Y3RlZCBmcm9tIDMyIGJpdCBzYWx0IGFuZCBhIDY0IGJpdCBjb3VudGVyKTsgd2VyZSB0aGUgc2Vj dXJpdHkgZ3VhcmFudGVlcyBmcm9tIHRoZSBvcmlnaW5hbCBwYXBlciB0b28gd2Vhaz8gIElmIG5v dCwgd2hhdCBoYXMgY2hhbmdlZD8NCg0KVGhlIHF1YWRyYXRpYyBiZWhhdmlvciBpbiB0aGUgc2Vj dXJpdHkgcHJvb2ZzIGFyZSB0aGVyZSBmb3IganVzdCBhYm91dCBhbnkgYmxvY2sgY2lwaGVyIG1v ZGUsIGFuZCBpcyB0aGUgcmVhc29uIHdoeSB5b3Ugd2FudCB0byBzdGF5IHdlbGwgYmVsb3cgdGhl IGJpcnRoZGF5IGJvdW5kLiAgSG93ZXZlciwgdGhhdCdzIGFzIHRydWUgZm9yIChzYXkpIENCQyBt b2RlIGFzIGl0IGlzIGZvciBHQ00NCg0K From nobody Tue Dec 15 15:48:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2BD71B2CF8 for ; Tue, 15 Dec 2015 15:47:59 -0800 (PST) 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 Q_4lfpCH_ea5 for ; Tue, 15 Dec 2015 15:47:58 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD781B2CF4 for ; Tue, 15 Dec 2015 15:47:58 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id u65so20637482qkh.2 for ; Tue, 15 Dec 2015 15:47:58 -0800 (PST) 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=Y0ftMvfXvKqFkWSNWblKxBRlSke8jssttLg8pKzP+zk=; b=pzYUpK/Qly3oU691nXYdKohjI1uzRK8xQgjLDkGU7HEwtBXpUeX/wto81CACFAx7e2 FpfRugcNFGA3OHoq4MdMAH5Zvi2viV/eDyuvrDrhmCCsbAejyNh+5tgFhxr5J1Rke1eH Au/bnZg7qoFpT64p85v3WBNYsoEcw1A4wduUoHDOaAHdDVmW76cUxuOkqg71K1PWHhZW +CkmYjik+owXOBzdQhAoOjTJHGOqhb41RDzRsGj3msydiBTu7LZ9d6TBR6e7OF2W0WL1 Ez7eQ+GjDY9QcGENTT4XXu42NIzYx84ZWGpCEyaFqtCFICeyLyaSVfO0frMMiMpi4hvw d9Qw== MIME-Version: 1.0 X-Received: by 10.13.229.71 with SMTP id o68mr26295219ywe.326.1450223277662; Tue, 15 Dec 2015 15:47:57 -0800 (PST) Received: by 10.129.148.131 with HTTP; Tue, 15 Dec 2015 15:47:57 -0800 (PST) Received: by 10.129.148.131 with HTTP; Tue, 15 Dec 2015 15:47:57 -0800 (PST) In-Reply-To: <6674a4ec51fe4e158929bf429260d6ea@XCH-RTP-006.cisco.com> References: <6674a4ec51fe4e158929bf429260d6ea@XCH-RTP-006.cisco.com> Date: Tue, 15 Dec 2015 18:47:57 -0500 Message-ID: From: Watson Ladd To: "Scott Fluhrer (sfluhrer)" Content-Type: multipart/alternative; boundary=94eb2c07ef4a4f67e90526f86b98 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data volume 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: Tue, 15 Dec 2015 23:48:00 -0000 --94eb2c07ef4a4f67e90526f86b98 Content-Type: text/plain; charset=UTF-8 On Dec 15, 2015 6:08 PM, "Scott Fluhrer (sfluhrer)" wrote: > > > > > -----Original Message----- > > From: Watson Ladd [mailto:watsonbladd@gmail.com] > > Sent: Tuesday, December 15, 2015 5:38 PM > > To: Scott Fluhrer (sfluhrer) > > Cc: Eric Rescorla; tls@ietf.org > > Subject: Re: [TLS] Data volume limits > > > > On Tue, Dec 15, 2015 at 5:01 PM, Scott Fluhrer (sfluhrer) > > wrote: > > > Might I enquire about the cryptographical reason behind such a limit? > > > > > > > > > > > > Is this the limit on the size of a single record? GCM does have a > > > limit approximately there on the size of a single plaintext it can > > > encrypt. For TLS, it encrypts a record as a single plaintext, and so > > > this would apply to extremely huge records. > > > > The issue is the bounds in Iwata-Ohashai-Minematsu's paper, which show a > > quadratic confidentiality loss after a total volume sent. This is an exploitable > > issue. > > Actually, the main result of that paper was that GCM with nonces other than 96 bits were less secure than previous thought (or, rather, that the previous proofs were wrong, and what they can prove is considerably worse; whether their proof is tight is an open question). They address 96 bit nonces as well, however the results they get are effectively unchanged from the original GCM paper. I had thought that TLS used 96 bit nonces (constructed from 32 bit salt and a 64 bit counter); were the security guarantees from the original paper too weak? If not, what has changed? > > The quadratic behavior in the security proofs are there for just about any block cipher mode, and is the reason why you want to stay well below the birthday bound. However, that's as true for (say) CBC mode as it is for GCM That's correct. And when we crunch the numbers assuming 2^60 is negligible out comes 2^36 bytes. This doesn't hold for ChaCha20. > --94eb2c07ef4a4f67e90526f86b98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Dec 15, 2015 6:08 PM, "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Watson Ladd [mailto:watsonbladd@gmail.com]
> > Sent: Tuesday, December 15, 2015 5:38 PM
> > To: Scott Fluhrer (sfluhrer)
> > Cc: Eric Rescorla; tls@ietf.org
> > Subject: Re: [TLS] Data volume limits
> >
> > On Tue, Dec 15, 2015 at 5:01 PM, Scott Fluhrer (sfluhrer)
> > <sfluhrer@cisco.com&= gt; wrote:
> > > Might I enquire about the cryptographical reason behind such= a limit?
> > >
> > >
> > >
> > > Is this the limit on the size of a single record?=C2=A0 GCM = does have a
> > > limit approximately there on the size of a single plaintext = it can
> > > encrypt.=C2=A0 For TLS, it encrypts a record as a single pla= intext, and so
> > > this would apply to extremely huge records.
> >
> > The issue is the bounds in Iwata-Ohashai-Minematsu's paper, w= hich show a
> > quadratic confidentiality loss after a total volume sent. This is= an exploitable
> > issue.
>
> Actually, the main result of that paper was that GCM with nonces other= than 96 bits were less secure than previous thought (or, rather, that the = previous proofs were wrong, and what they can prove is considerably worse; = whether their proof is tight is an open question).=C2=A0 They address 96 bi= t nonces as well, however the results they get are effectively unchanged fr= om the original GCM paper.=C2=A0 I had thought that TLS used 96 bit nonces = (constructed from 32 bit salt and a 64 bit counter); were the security guar= antees from the original paper too weak?=C2=A0 If not, what has changed? >
> The quadratic behavior in the security proofs are there for just about= any block cipher mode, and is the reason why you want to stay well below t= he birthday bound.=C2=A0 However, that's as true for (say) CBC mode as = it is for GCM

That's correct. And when we crunch the numbers assuming = 2^60 is negligible out comes 2^36 bytes. This doesn't hold for ChaCha20= .
>

--94eb2c07ef4a4f67e90526f86b98-- From nobody Tue Dec 15 15:48:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24151B2CF8 for ; Tue, 15 Dec 2015 15:48:54 -0800 (PST) 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, HTML_MESSAGE=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 Th0Sa7PTp0Xy for ; Tue, 15 Dec 2015 15:48:53 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8660C1B2CF4 for ; Tue, 15 Dec 2015 15:48:50 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id t125so39753973qkh.3 for ; Tue, 15 Dec 2015 15:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fbklgIgdvuQG+fr9TABTa+18JwSxhaFNLvVvCCFuL60=; b=Tf9+viJZ9t2YNJztYC3ou3DAIzTMx7FnbcoUPnuzWPolh3VvcphN2Uxq80BDMdsweT heSLQeWFea0CwM8gJvzeRWSmQdH973EFgWEi8hInmZF3uukc28Flot70cwK9g6pQn2My ZNBUnFhVLlWtJwbApVFldTHrSlO68/WQUS7+jOTCirlXZr9RKGYFa6mY1WnsXlEQ/FOe GJvHjBUzV1k/woFZONjhm1meP7W9HE4t7fdsaLCr1eymgrthwL1iVg06jhV/N2+cZ4Ol AXmTECirDGm5NEBPhXcndWP4qkdn9rDE79/LOT3QILbhl4trAih+EENxwpcUsOvDAp+O UMYQ== 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=fbklgIgdvuQG+fr9TABTa+18JwSxhaFNLvVvCCFuL60=; b=KBTyYkq0pijqOSYJY8JUZtS5THu3hB9372J2hbjTuRGVkyjlyg8EnVFMS2hxWcMzfG OlGGy+U9UCKt6eqDl7sVM8z1HoOeRnz1s4ULE1KlN9QIca8qtYHuPorQ6b19WU6RjXWI jJYw8c4RpkmI7zMJIFCpvp7isBuJopIW4JGP2Ml237TnNPN2Gg1lc5tceHAw97CSf6ge SN3H3ItdNT+6dmL+OCyIoK3BlRm1sJ+XMpQs5VZ/Kc4zB4OVBzkkHWvNvTCsXtq9k4VZ PhvjHDekXXa6NDAq+DrJD83xw2pn+FulxPclWfa5FMzASZNCQGRiy4/hRF/ml44JLoYc 5n3Q== X-Gm-Message-State: ALoCoQmI80yLYNf6oQmgZLClgKkVV9GIQlnlACXDsctjQMMBafCuV2XxYzeXgUQQ3UN3xxoF81rd3pMLjazO3otDtBhwxwcOjA== X-Received: by 10.13.193.4 with SMTP id c4mr10623080ywd.192.1450223329682; Tue, 15 Dec 2015 15:48:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 15 Dec 2015 15:48:10 -0800 (PST) In-Reply-To: <6674a4ec51fe4e158929bf429260d6ea@XCH-RTP-006.cisco.com> References: <6674a4ec51fe4e158929bf429260d6ea@XCH-RTP-006.cisco.com> From: Eric Rescorla Date: Tue, 15 Dec 2015 15:48:10 -0800 Message-ID: To: "Scott Fluhrer (sfluhrer)" Content-Type: multipart/alternative; boundary=001a114caa9e695bbf0526f86e61 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Tue, 15 Dec 2015 23:48:55 -0000 --001a114caa9e695bbf0526f86e61 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer) < sfluhrer@cisco.com> wrote: > > > > -----Original Message----- > > From: Watson Ladd [mailto:watsonbladd@gmail.com] > > Sent: Tuesday, December 15, 2015 5:38 PM > > To: Scott Fluhrer (sfluhrer) > > Cc: Eric Rescorla; tls@ietf.org > > Subject: Re: [TLS] Data volume limits > > > > On Tue, Dec 15, 2015 at 5:01 PM, Scott Fluhrer (sfluhrer) > > wrote: > > > Might I enquire about the cryptographical reason behind such a limit? > > > > > > > > > > > > Is this the limit on the size of a single record? GCM does have a > > > limit approximately there on the size of a single plaintext it can > > > encrypt. For TLS, it encrypts a record as a single plaintext, and so > > > this would apply to extremely huge records. > > > > The issue is the bounds in Iwata-Ohashai-Minematsu's paper, which show a > > quadratic confidentiality loss after a total volume sent. This is an > exploitable > > issue. > > Actually, the main result of that paper was that GCM with nonces other > than 96 bits were less secure than previous thought (or, rather, that the > previous proofs were wrong, and what they can prove is considerably worse; > whether their proof is tight is an open question). They address 96 bit > nonces as well, however the results they get are effectively unchanged from > the original GCM paper. I had thought that TLS used 96 bit nonces > (constructed from 32 bit salt and a 64 bit counter); TLS 1.3 uses a 96-bit nonce constructed by masking the counter with a random value. were the security guarantees from the original paper too weak? If not, > what has changed? > > The quadratic behavior in the security proofs are there for just about any > block cipher mode, and is the reason why you want to stay well below the > birthday bound. The birthday bound here is 2^{64}, right? -Ekr > However, that's as true for (say) CBC mode as it is for GCM > > --001a114caa9e695bbf0526f86e61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer) <sfluhrer@c= isco.com> wrote:


> -----Original Message-----
> From: Watson Ladd [mailto:wat= sonbladd@gmail.com]
> Sent: Tuesday, December 15, 2015 5:38 PM
> To: Scott Fluhrer (sfluhrer)
> Cc: Eric Rescorla; tls@ietf.org > Subject: Re: [TLS] Data volume limits
>
> On Tue, Dec 15, 2015 at 5:01 PM, Scott Fluhrer (sfluhrer)
> <sfluhrer@cisco.com> w= rote:
> > Might I enquire about the cryptographical reason behind such a li= mit?
> >
> >
> >
> > Is this the limit on the size of a single record?=C2=A0 GCM does = have a
> > limit approximately there on the size of a single plaintext it ca= n
> > encrypt.=C2=A0 For TLS, it encrypts a record as a single plaintex= t, and so
> > this would apply to extremely huge records.
>
> The issue is the bounds in Iwata-Ohashai-Minematsu's paper, which = show a
> quadratic confidentiality loss after a total volume sent. This is an e= xploitable
> issue.

Actually, the main result of that paper was that GCM with nonces oth= er than 96 bits were less secure than previous thought (or, rather, that th= e previous proofs were wrong, and what they can prove is considerably worse= ; whether their proof is tight is an open question).=C2=A0 They address 96 = bit nonces as well, however the results they get are effectively unchanged = from the original GCM paper.=C2=A0 I had thought that TLS used 96 bit nonce= s (constructed from 32 bit salt and a 64 bit counter);
TLS 1.3 uses a 96-bit nonce constructed by masking the counter= with a random
value.

were the security guarantees from the original paper too weak?=C2= =A0 If not, what has changed?

The quadratic behavior in the security proofs are there for just about any = block cipher mode, and is the reason why you want to stay well below the bi= rthday bound.

The birthday bound here is 2^= {64}, right?

-Ekr
=C2=A0
=C2=A0 However, that's as true for (say) CBC mode = as it is for GCM


--001a114caa9e695bbf0526f86e61-- From nobody Tue Dec 15 16:00:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018E51A87C9 for ; Tue, 15 Dec 2015 16:00:47 -0800 (PST) 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, 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 xcMfniNoY-kn for ; Tue, 15 Dec 2015 16:00:45 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02961A6F3B for ; Tue, 15 Dec 2015 16:00:45 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id i186so15394964oia.2 for ; Tue, 15 Dec 2015 16:00:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4GGYIGkg3brKQvMjXPEcx0S5KfiCNajTwdliNq8FHVY=; b=n0bO6TAseW/x9AaJHr6ZfgSJcl23TNVEZgMgFmSs3QcROT/YNUrhNGVFlQN5biM0lN dy2jL0FDlu/mYLizfTGCLdu6Frz3RivgRF9ZA4MFItzv9LBDA/IBLDt2tYk+i7RDOuq/ WKPPir+1E8UAcDDiT4xpkHk8yoHAlPUPtmYdDCTRu31qnw6CABu5Zm+TqfaqaesMTOf2 g0vrO2s1XKyYxoOQK2bUOSSu1ZpCHagb5np5nDHxbL8w58uIKx7LtffBTbaV+Lxm/8NR rWbmQuuA6qjIqV4M+KbMX+17JN49GDn3d9K/7H/lUdt8bCPYgYbaCLbMkPV83LOwLU1M iBBg== 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=4GGYIGkg3brKQvMjXPEcx0S5KfiCNajTwdliNq8FHVY=; b=KfqADL/urtmCfi1feCcDjymuHladPtGYTCcMyVSfMIuQrIB0GytRBLx/KNWM2ZHV+k btZdEjG1q/sxKqKhMLYNTgWvVnRPtNjcyEBjQOtaPNowUhaRgLrVHeKN1YLlxL+gOgHZ b67oTF8/YlYtG8N/EZeDaFuVxHUEssDEGMJ2pO5mGGIPYhd4M7d4zygWuFqw9vPA1eWz Xx3eEaAhv+ZE/k/t08w6L/eNIT/DtiZfunR0isySDL+K4mjZXNwDIXE4E61Afj+ZNX1k /XUtukL5JiDLhR6d9cd/x9nac1dfS2iZP5/zGaob7JpFcULc1WUr/b7gAgkzW6711Yut SyTw== X-Gm-Message-State: ALoCoQkYMl1kMmGDNAylMJ5YPXEjE4W8qUQ8GM19JZvicl2t0bsDUMlSPP+Kqc3OsgOZ87NThxzFzkuK3cfIAX9XTvZczi/ZsQ== MIME-Version: 1.0 X-Received: by 10.202.189.7 with SMTP id n7mr25557508oif.55.1450224044974; Tue, 15 Dec 2015 16:00:44 -0800 (PST) Received: by 10.76.105.169 with HTTP; Tue, 15 Dec 2015 16:00:44 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Dec 2015 14:00:44 -1000 Message-ID: From: Brian Smith To: Watson Ladd Content-Type: multipart/alternative; boundary=001a113d70320bbbc10526f89995 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 00:00:47 -0000 --001a113d70320bbbc10526f89995 Content-Type: text/plain; charset=UTF-8 Watson Ladd wrote: > The issue is the bounds in Iwata-Ohashai-Minematsu's paper, which show > a quadratic confidentiality loss after a total volume sent. This is an > exploitable issue. > Please explain in more detail how you got "2^36 bytes" for a nonce size of 96 bits from the Iwata-Ohashai-Minematsu paper [1]. [1] https://eprint.iacr.org/2012/438.pdf Also, the Niwa-Ohashi-Minematsu-Iwata follow-up paper [2] change things in any way? In particular, note that it concludes "The new security bounds improve the security bounds in [11] by a factor of 2^17, and they show that the security of GCM is actually close to what was originally claimed in [17,18]." A factor of 2^17 difference is pretty significant as far as this is concerned, AFAICT. [2] https://eprint.iacr.org/2015/214.pdf Cheers, Brian -- https://briansmith.org/ --001a113d70320bbbc10526f89995 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wats= on Ladd <watsonbladd@gmail.com> wrote:
The issue is the bounds in Iwata-Ohashai-Minematsu's paper, which sh= ow
a quadratic confidentiality loss after a total volume sent. This is an
exploitable issue.

Please explain in mo= re detail how you got "2^36 bytes" for a nonce size of 96 bits fr= om the Iwata-Ohashai-Minematsu paper [1].


Also, the Niwa= -Ohashi-Minematsu-Iwata follow-up paper [2] change things in any way? In pa= rticular, note that it concludes "The new security bounds improve the = security bounds in [11] by a factor of 2^17, and they show that the security of GCM is actually close to what w= as originally claimed in [17,18]."

A factor o= f 2^17 difference is pretty significant as far as this is concerned, AFAICT= .


=
Cheers,
Brian
--

--001a113d70320bbbc10526f89995-- From nobody Tue Dec 15 16:09:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A6A1A8842 for ; Tue, 15 Dec 2015 16:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 FdmddjnSNZXY for ; Tue, 15 Dec 2015 16:09:02 -0800 (PST) Received: from vsp2.ballou.se (vsp2.ballou.se [91.189.40.83]) by ietfa.amsl.com (Postfix) with SMTP id D8A241A8841 for ; Tue, 15 Dec 2015 16:09:01 -0800 (PST) X-Halon-ID: 3419824f-a389-11e5-976f-0050569222ec X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04 Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp2.ballou.se (Halon Mail Gateway) with ESMTP for ; Wed, 16 Dec 2015 01:08:58 +0100 (CET) Received: from [192.168.0.190] (c-1ec0e555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.192.30]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id C0DECC9378 for ; Wed, 16 Dec 2015 01:08:57 +0100 (CET) References: <6674a4ec51fe4e158929bf429260d6ea@XCH-RTP-006.cisco.com> To: tls@ietf.org From: =?UTF-8?Q?Henrick_Hellstr=c3=b6m?= Message-ID: <5670AB96.9000602@streamsec.se> Date: Wed, 16 Dec 2015 01:08:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list 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, 16 Dec 2015 00:09:04 -0000 On 2015-12-16 00:48, Eric Rescorla wrote: > > > On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer) > > wrote: > The quadratic behavior in the security proofs are there for just > about any block cipher mode, and is the reason why you want to stay > well below the birthday bound. > > > The birthday bound here is 2^{64}, right? > > -Ekr > > However, that's as true for (say) CBC mode as it is for GCM Actually, no. Using the sequence number as part of the effective nonce, means that it won't collide. There is no relevant bound for collisions in the nonces or in the CTR state, because they simply won't happen (unless there is an implementation flaw). There won't be any potentially exploitable collisions. However, theoretically, the GHASH state might collide with a 2^{64} birthday bound. This possibility doesn't seem entirely relevant, though. From nobody Tue Dec 15 16:31:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9381A0056 for ; Tue, 15 Dec 2015 16:31:06 -0800 (PST) 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 EKktSEgN2B8t for ; Tue, 15 Dec 2015 16:31:05 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512841A004D for ; Tue, 15 Dec 2015 16:31:05 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id p187so41014852qkd.1 for ; Tue, 15 Dec 2015 16:31:05 -0800 (PST) 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=DIRNZW2wALP7P+dh0hLPvUc4AUSGllE74rQAe+U8VJo=; b=w12CPkTH8U1DrLrJ16PFsvohS8y1f/XTkfr2FxbZZjbhNhzHH8jp747v10HYqy/BNx vNAy11+6232JatS8nhKD2EAC+MCFmVDp5ozKE5jUNOx2au2ARd3c6cWGQfcIVJpCT85a DuC0satCdHqgTE1gphM468aoSPuNnJXb/JT63mevcSGX94z3lsqCHbqZkZO7uaJ5/yT7 m6JhUMwwyPBq945nfCfz/W7/uQl51jdG73UqKmXjUNgp/TbKZ9RowwtSlmF2dF6bpbL2 uBRS0OF3crGnRf8Uz7hD6DmwFSt+SzsnGzMUMtgwncgI7rv70Y8bPxN6loKKCh6mks4R T04g== MIME-Version: 1.0 X-Received: by 10.129.57.135 with SMTP id g129mr24598498ywa.244.1450225864428; Tue, 15 Dec 2015 16:31:04 -0800 (PST) Received: by 10.129.148.131 with HTTP; Tue, 15 Dec 2015 16:31:04 -0800 (PST) Received: by 10.129.148.131 with HTTP; Tue, 15 Dec 2015 16:31:04 -0800 (PST) In-Reply-To: <5670AB96.9000602@streamsec.se> References: <6674a4ec51fe4e158929bf429260d6ea@XCH-RTP-006.cisco.com> <5670AB96.9000602@streamsec.se> Date: Tue, 15 Dec 2015 19:31:04 -0500 Message-ID: From: Watson Ladd To: =?UTF-8?Q?Henrick_Hellstr=C3=B6m?= Content-Type: multipart/alternative; boundary=001a114c78fe7e53110526f9051d Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 00:31:07 -0000 --001a114c78fe7e53110526f9051d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Dec 15, 2015 7:09 PM, "Henrick Hellstr=C3=B6m" wr= ote: > > On 2015-12-16 00:48, Eric Rescorla wrote: >> >> >> >> On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer) >> > wrote: >> The quadratic behavior in the security proofs are there for just >> about any block cipher mode, and is the reason why you want to stay >> well below the birthday bound. >> >> >> The birthday bound here is 2^{64}, right? >> >> -Ekr >> >> However, that's as true for (say) CBC mode as it is for GCM > > > Actually, no. > > Using the sequence number as part of the effective nonce, means that it won't collide. There is no relevant bound for collisions in the nonces or in the CTR state, because they simply won't happen (unless there is an implementation flaw). There won't be any potentially exploitable collisions= . You don't understand the issue. The issue is PRP not colliding, whereas PRF can. > > However, theoretically, the GHASH state might collide with a 2^{64} birthday bound. This possibility doesn't seem entirely relevant, though. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --001a114c78fe7e53110526f9051d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Dec 15, 2015 7:09 PM, "Henrick Hellstr=C3=B6m" <henrick@streamsec.se> wrote:
>
> On 2015-12-16 00:48, Eric Rescorla wrote:
>>
>>
>>
>> On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer)
>> <sfluhrer@cisco.com &= lt;mailto:sfluhrer@cisco.com>&= gt; wrote:
>> =C2=A0 =C2=A0 The quadratic behavior in the security proofs are th= ere for just
>> =C2=A0 =C2=A0 about any block cipher mode, and is the reason why y= ou want to stay
>> =C2=A0 =C2=A0 well below the birthday bound.
>>
>>
>> The birthday bound here is 2^{64}, right?
>>
>> -Ekr
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0However, that's as true for (say) C= BC mode as it is for GCM
>
>
> Actually, no.
>
> Using the sequence number as part of the effective nonce, means that i= t won't collide. There is no relevant bound for collisions in the nonce= s or in the CTR state, because they simply won't happen (unless there i= s an implementation flaw). There won't be any potentially exploitable c= ollisions.

You don't understand the issue. The issue is PRP not col= liding, whereas PRF can.

>
> However, theoretically, the GHASH state might collide with a 2^{64} bi= rthday bound. This possibility doesn't seem entirely relevant, though.<= br> >
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--001a114c78fe7e53110526f9051d-- From nobody Tue Dec 15 16:39:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75D41A00AC for ; Tue, 15 Dec 2015 16:39:48 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 EBZiQ6a8GoZu for ; Tue, 15 Dec 2015 16:39:46 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154: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 D026C1A00A3 for ; Tue, 15 Dec 2015 16:39:46 -0800 (PST) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-04v.sys.comcast.net with comcast id u0fG1r0025AAYLo010fmtk; Wed, 16 Dec 2015 00:39:46 +0000 Received: from [IPv6:::1] ([73.170.34.26]) by resomta-po-15v.sys.comcast.net with comcast id u0fl1r0060ZpzqZ010flVD; Wed, 16 Dec 2015 00:39:46 +0000 Message-ID: <5670B2D1.7050201@brainhub.org> Date: Tue, 15 Dec 2015 16:39:45 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: tls@ietf.org References: <6674a4ec51fe4e158929bf429260d6ea@XCH-RTP-006.cisco.com> <5670AB96.9000602@streamsec.se> In-Reply-To: <5670AB96.9000602@streamsec.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1450226386; bh=E8a3V6U5MgvkxeD3gsd3hi3S1LuKAFJr2aixGssORKc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QMFK76cH+mky71LjvlKBmwVvrmUVl0og6/yas46FIy8jurEkIHPhfnwRSZNymDaVG SUl41rAnCHs5ryVLs3ZtyJtXOHTgqIghWT5VNgcjzkrdWnaWNEdAhquRSfPWT3GaFe RR2HNw72btK8yW184AZwvQdZwftSUZmseY75URFwZwih247nHt77b+ZpczDJAQT9pM fA5fMsIo1oLg6Nb17cV66Ij/cLloYLzopqVcyilT+Hy6doN8lfCHxBxw/G3dwf+6CO QkyUbl4ZLoNobjlYK8FZjwLoZzGjL2uRrnBMhf6QEgKcNfzJOtDal5kDEpTjzDz3BY KoZmZ49SCzC7g== Archived-At: Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 00:39:49 -0000 On 12/15/2015 04:08 PM, Henrick Hellström wrote: > On 2015-12-16 00:48, Eric Rescorla wrote: >> >> >> On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer) >> > wrote: >> The quadratic behavior in the security proofs are there for just >> about any block cipher mode, and is the reason why you want to stay >> well below the birthday bound. >> >> >> The birthday bound here is 2^{64}, right? >> >> -Ekr >> >> However, that's as true for (say) CBC mode as it is for GCM > > Actually, no. > > Using the sequence number as part of the effective nonce, means that it won't collide. There is no relevant bound for collisions in the nonces or in the CTR state, because they simply won't happen (unless there is an implementation flaw). There won't be any potentially exploitable collisions. > Here is one attack that exploits such a collision https://www.ietf.org/mail-archive/web/openpgp/current/msg08345.html > However, theoretically, the GHASH state might collide with a 2^{64} birthday bound. This possibility doesn't seem entirely relevant, though. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Dec 15 16:46:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556111A00EE for ; Tue, 15 Dec 2015 16:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, 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 16w3v4bKKAXB for ; Tue, 15 Dec 2015 16:46:55 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91CC1A00D0 for ; Tue, 15 Dec 2015 16:46:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2316; q=dns/txt; s=iport; t=1450226814; x=1451436414; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=JLNhT0Fow/rQyWINd+tiJFHBb82mbqfTs0K/4hiqQC0=; b=a5oRZii6x1Fmq19eYbLp9Z5Agkb6hGEUQk3CEJaWxAe3MPaMQop7wCpN B98JctQf5lKcSYJTN8nFXFI2TymBGyI/oxd09cFfQDPGDtslMaBxe3anp X0juN2jx+Pb8f/vIitqc5jxPePqlzxJ8FZtOeVedEaGDv2zRIKAA4LcKG Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAgBctHBW/51dJa1egzqBPwa9UwENg?= =?us-ascii?q?WOGDQKBQTgUAQEBAQEBAYEKhDQBAQEEbAoPBAIBCBEEAQEBJwcyFAkIAgQBEgi?= =?us-ascii?q?IJ71dAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZWhH2JQAWNb4kNAY1AnSABHwEBQ?= =?us-ascii?q?oQEcoNsgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,434,1444694400"; d="scan'208";a="53740744" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Dec 2015 00:46:47 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id tBG0klA6013516 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Dec 2015 00:46:47 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Dec 2015 19:46:46 -0500 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1104.009; Tue, 15 Dec 2015 19:46:46 -0500 From: "Scott Fluhrer (sfluhrer)" To: "henrick@streamsec.se" , "tls@ietf.org" Thread-Topic: [TLS] Data volume limits Thread-Index: AQHRN321+GNchELNkkOmU2Gwkrt9SJ7MlZaAgABh3ID//7FHcIAAYjgAgAAFywD//7Rf8A== Date: Wed, 16 Dec 2015 00:46:46 +0000 Message-ID: References: <6674a4ec51fe4e158929bf429260d6ea@XCH-RTP-006.cisco.com> <5670AB96.9000602@streamsec.se> In-Reply-To: <5670AB96.9000602@streamsec.se> 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: [10.98.2.55] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 00:46:56 -0000 > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Henrick Hellstr=F6m > Sent: Tuesday, December 15, 2015 7:09 PM > To: tls@ietf.org > Subject: Re: [TLS] Data volume limits >=20 > On 2015-12-16 00:48, Eric Rescorla wrote: > > > > > > On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer) > > > wrote: > > The quadratic behavior in the security proofs are there for just > > about any block cipher mode, and is the reason why you want to stay > > well below the birthday bound. > > > > > > The birthday bound here is 2^{64}, right? > > > > -Ekr > > > > However, that's as true for (say) CBC mode as it is for GCM >=20 > Actually, no. >=20 > Using the sequence number as part of the effective nonce, means that it > won't collide. There is no relevant bound for collisions in the nonces or= in the > CTR state, because they simply won't happen (unless there is an > implementation flaw). There won't be any potentially exploitable collisio= ns. >=20 > However, theoretically, the GHASH state might collide with a 2^{64} birth= day > bound. This possibility doesn't seem entirely relevant, though. That is a good point, and deserves to be examined more. With CBC mode, there's a probability that two different ciphertext blocks w= ill happen to be identical; when that unlikely event happens, the attacker = can determine the bitwise difference between the corresponding plaintext bl= ocks (and thereby leak a small amount of plaintext) This doesn't happen with GCM. Instead, the distinguisher is of this form: = the attacker with a potential plaintext can compute the internal CTR values= for GCM; if he sees a duplicate value, he can deduce that that potential p= laintext wasn't the real one (because the internal CTR values never repeat)= . Assuming that they cannot distinguish AES with a random key from a random p= ermutation, that's the only thing they can learn. That is, when they prove that there is no distinguisher with better than 2^= {-64} advantage, what they are referring to (in practice) is that the attac= ker could eliminate a tiny fraction (1 out of 2^{64}) of the possible plain= texts; they gain no more information than that. From nobody Tue Dec 15 16:59:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F321A011D for ; Tue, 15 Dec 2015 16:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 QbXhy2wQkxa7 for ; Tue, 15 Dec 2015 16:59:40 -0800 (PST) Received: from vsp2.ballou.se (vsp2.ballou.se [91.189.40.83]) by ietfa.amsl.com (Postfix) with SMTP id 8072B1A014F for ; Tue, 15 Dec 2015 16:59:38 -0800 (PST) X-Halon-ID: 470ae048-a390-11e5-976f-0050569222ec X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04 Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp2.ballou.se (Halon Mail Gateway) with ESMTP; Wed, 16 Dec 2015 01:59:36 +0100 (CET) Received: from [192.168.0.190] (c-1ec0e555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.192.30]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id E4ABEC9378; Wed, 16 Dec 2015 01:59:35 +0100 (CET) References: <6674a4ec51fe4e158929bf429260d6ea@XCH-RTP-006.cisco.com> <5670AB96.9000602@streamsec.se> To: Watson Ladd From: =?UTF-8?Q?Henrick_Hellstr=c3=b6m?= Message-ID: <5670B774.5050605@streamsec.se> Date: Wed, 16 Dec 2015 01:59:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list 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, 16 Dec 2015 00:59:42 -0000 On 2015-12-16 01:31, Watson Ladd wrote: > You don't understand the issue. The issue is PRP not colliding, whereas > PRF can. Oh, but I concur. This means that if you observe two same valued cipher text blocks, you know that the corresponding key stream blocks can't be identical, and deduce that the corresponding plain text blocks have to be different. Such observations consequently leak information about the plain text, in the rare and unlikely event they actually occur. However, calling it an exploitable weakness is a bit of a stretch. AES-CBC is likely to loose confidentiality slightly faster, for typical plain texts. From nobody Tue Dec 15 18:40:45 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A341A1AE8 for ; Tue, 15 Dec 2015 18:40:43 -0800 (PST) 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 RfHza7-yl7Rk for ; Tue, 15 Dec 2015 18:40:42 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2E81A1AD9 for ; Tue, 15 Dec 2015 18:40:42 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id to4so45990119igc.0 for ; Tue, 15 Dec 2015 18:40:42 -0800 (PST) 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=y7NSi4PlR8fVJiWQSry/a1/MC/tynG18M0NmZ/6hm80=; b=bBL+yIKYuJefQAvO33bBAiLCRllRV8OUujE0g5HC1U1uQb1VmsL9VQfLQl82Gm/ICt 1PLcJzEOe8RsZo257zdgt307wnhc8x1zv65reaL9WS+U1IaTBQQDjGRJRx3Cd/MHw0iQ ehLixhIl8qaEW8XlGs70ze05C2EHVQwjz3fr2kMfAb89RvEPLqGZriXE0q+tEe7Nfqaj 7ticufZPVDQQ5YyanrqVBOGi4TASSwDuwkYJNOhWdEvn7xntLncWwDGoh5Yo/QEJ/FmE dY4Uv+T9KGFXnt4KDDuIii74V/cbpfxZmXcatoZvMuB1lGPoOtTGZ+UiavA7HeX9ZNiE C7WA== MIME-Version: 1.0 X-Received: by 10.50.6.104 with SMTP id z8mr7928908igz.58.1450233641536; Tue, 15 Dec 2015 18:40:41 -0800 (PST) Received: by 10.36.149.130 with HTTP; Tue, 15 Dec 2015 18:40:41 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Dec 2015 13:40:41 +1100 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 02:40:43 -0000 On 16 December 2015 at 08:14, Eric Rescorla wrote: > > I wanted to get people's opinions on whether that's actually what we want > or whether we should (as is my instinct) allow people to use ChaCha > for longer periods. Whatever the actual limits are, I think that implementatios should be encouraged to rekey more strongly. If 2^36 is the number, then I can see that being reached in some applications. That means that we need the rekey feature to exist. If we are going to have that feature, then we need to make sure that it works. And suggesting a stupidly high limit (e.g., ChaCha being greater than 2^96) leaves people thinking that they can skip implementation and testing of the rekey facility; or it just goes unused. If it's not in use, then we'll have a good chance of creating a protocol feature we can't rely on if it really is needed. In light of that, the actual limits don't matter that much to me. As David McGrew suggested, set a limit at 2^32 and avoid having to think too hard about how close to the failure point you might be. From nobody Tue Dec 15 19:01:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E041A1B91 for ; Tue, 15 Dec 2015 19:01:35 -0800 (PST) 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, 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 1cJ0H3DLsxw1 for ; Tue, 15 Dec 2015 19:01:34 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9C01A1B89 for ; Tue, 15 Dec 2015 19:01:33 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id i186so17433625oia.2 for ; Tue, 15 Dec 2015 19:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Tzqw2Wvk4CPE8/xEcCxVHo+Ch9g2X6XxOK5G3+1ahPw=; b=y3qa7fyhgzJSjurB521dVdKi8BhhEg+IBAPw1b3fLk5kARUSc8/LmFm5Nk7RolszrS Y/CcFLlaAcg0nSy12mOEUQi5JvrCPB7iVLmHtl/PnfY+L2B1CiS6ezikuWexpZYZLf5M CC7gIwFwAPqZgfORlB/SNUv3er5rHNzPhJeinARSsatIg//MdhgEa5oLrqkAQYStaXgp XVCmpwO4uyh1oJxNlISEgOWCZ93RqT1DPWHTkOheqSZzv3V9gtOai5XQKLtJHMuq3Af+ pFaUDMF6ZG9n9tOHfm2tm7/+117pI4n75Q6w5Rz8c5K9f0QZ2fapDDwto3AjRotwpxKh CssA== 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=Tzqw2Wvk4CPE8/xEcCxVHo+Ch9g2X6XxOK5G3+1ahPw=; b=l1k/z6lx23r0CPYKHZrMMFYgfV5neA2p5tzEj1J8Fkg1Zvs+69BrcrJwulBjRdUX/W rHd8etIi45L5ncc8T34jAPXaHeV40j9Xo3OXtsxkIHI1bBz9uBfoiOj5P+nNSAkPDhC4 sznPkCuCZ45nwl+pyE1Q11jzrw4xidnWIzb2bF5S0KvcPgX2itBpg/n4fjWyF3vcQgO1 o4RHfrdkbiIYTyeicjfSumkUg2D2sXIZv7/WdMSL8AoaWNw7KcG2fSW3LMFkh0/dMyDf 1dhJp2DcVZeuj/F5jXPvA/j4QwV6inoX3n1ZckdxARPINkAepj/gfEvINoWoUgYD5F/D 30LA== X-Gm-Message-State: ALoCoQnVmguVNVklE9o0OG9pEKsWlP+UXlFC0SSFGpPCGROh6U90AdQ+K7Q4D5EcMSgIWwiCF8TB1nqbcXXwO+TbmUFmhq+dYQ== MIME-Version: 1.0 X-Received: by 10.202.60.195 with SMTP id j186mr31361516oia.70.1450234893350; Tue, 15 Dec 2015 19:01:33 -0800 (PST) Received: by 10.76.82.41 with HTTP; Tue, 15 Dec 2015 19:01:33 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Dec 2015 17:01:33 -1000 Message-ID: From: Brian Smith To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113cd33ca8d48b0526fb1fd7 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 03:01:35 -0000 --001a113cd33ca8d48b0526fb1fd7 Content-Type: text/plain; charset=UTF-8 Martin Thomson wrote: > Whatever the actual limits are, I think that implementatios should be > encouraged to rekey more strongly. > Why? > And suggesting a stupidly high limit (e.g., ChaCha being > greater than 2^96) leaves people thinking that they can skip > implementation and testing of the rekey facility; or it just goes > unused. If it's not in use, then we'll have a good chance of creating > a protocol feature we can't rely on if it really is needed. > I think this is exactly why the limit matters. If we are not in danger of reaching the limit, then we don't need the rekeying mechanism and it should be removed. The rekeying mechanism adds considerable complexity and that complexity needs to be justified. Alternatively, we'd need a new justification for the rekeying mechanism. The new justification would affect the design of the rekeying mechanism. For example, if the purpose of the rekeying mechanism is to get similar effects to, say, the Axolotl ratchet, then we should ensure that the rekeying mechanism actually has similar properties to Axolotl. In light of that, the actual limits don't matter that much to me. As > David McGrew suggested, set a limit at 2^32 and avoid having to think > too hard about how close to the failure point you might be. First, let's figure out why TLS 1.3 needs a rekeying mechanism, if it does. Then we can figure out how frequently we should suggest rekeying occur based on sound reasoning. Cheers, Brian -- https://briansmith.org/ --001a113cd33ca8d48b0526fb1fd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Thomson <martin.thomson@gmail.com> wrote:
Whatever the actual limits are, I think that implementatios sho= uld be
encouraged to rekey more strongly.

Why?=
=C2=A0
And suggesting a stupidly high limi= t (e.g., ChaCha being
greater than 2^96) leaves people thinking that they can skip
implementation and testing of the rekey facility; or it just goes
unused.=C2=A0 If it's not in use, then we'll have a good chance of = creating
a protocol feature we can't rely on if it really is needed.

I think this is exactly why the limit matters. If = we are not in danger of reaching the limit, then we don't need the reke= ying mechanism and it should be removed. The rekeying mechanism adds consid= erable complexity and that complexity needs to be justified.

=
Alternatively, we'd need a new justification for the rekeyin= g mechanism. The new justification would affect the design of the rekeying = mechanism. For example, if the purpose of the rekeying mechanism is to get = similar effects to, say, the Axolotl ratchet, then we should ensure that th= e rekeying mechanism actually has similar properties to Axolotl.
=
In light of that, the actual limits don't ma= tter that much to me.=C2=A0 As
David McGrew suggested, set a limit at 2^32 and avoid having to think
too hard about how close to the failure point you might be.

First, let's figure out why TLS 1.3 needs a rekeying m= echanism, if it does. Then we can figure out how frequently we should sugge= st rekeying occur based on sound reasoning.

Cheers= ,
Brian
--
--001a113cd33ca8d48b0526fb1fd7-- From nobody Tue Dec 15 19:24:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82EF1A1BE7 for ; Tue, 15 Dec 2015 19:24:25 -0800 (PST) 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 09ERdxW-Y7ue for ; Tue, 15 Dec 2015 19:24:23 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B82B1A1BDC for ; Tue, 15 Dec 2015 19:24:22 -0800 (PST) Received: by mail-ig0-x22e.google.com with SMTP id to4so47094041igc.0 for ; Tue, 15 Dec 2015 19:24:22 -0800 (PST) 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=GYH0IZvwzKWAdeeWWx45C6Sek07U9RR0odo42elF46w=; b=0GKwEx2JwWyJV6QnUsPu7dFRbmTg7k0ZjTzOet8XOjyp0eWDIjKAoTSvbMZWGgkRkg 1vpFgM5zotmpHJm0dKimqFXdo13xrmbutNs70MbD/NnVQXYSGRlEzw9fbKiPLjSQPfSw OjUUDVTIxVFHFZrtPS5caGHasYcOBHpZRkPPlM/heNKr1m1Wj52F/g+Az+rZo1W5jHea 0eEDA+zLFxrKycqKsPZ9cttIziaI62wnaq07Opvb2btjadA5+JH1W8vJigyS5bdJku2R sEMlSdr8ucctGvfoQ7UVoj2IrCZeG3DfSK5Nn0mecwZJUgeKubYprKfJUNSSSshq/VjK A81Q== MIME-Version: 1.0 X-Received: by 10.107.33.203 with SMTP id h194mr35659934ioh.108.1450236261538; Tue, 15 Dec 2015 19:24:21 -0800 (PST) Received: by 10.36.149.130 with HTTP; Tue, 15 Dec 2015 19:24:21 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Dec 2015 14:24:21 +1100 Message-ID: From: Martin Thomson To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 03:24:25 -0000 On 16 December 2015 at 14:01, Brian Smith wrote: > Martin Thomson wrote: > Why? If there were a stupidly high limit, then I would argue for no rekeying facility. But the numbers Watson ran suggested that GCM starts to look shaky at 2^36. That's too low for some applications. For the rest of the argument I suggest you reread my last mail. From nobody Tue Dec 15 19:29:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305DF1A1EF9 for ; Tue, 15 Dec 2015 19:29:36 -0800 (PST) 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 bf1IoINZIqs3 for ; Tue, 15 Dec 2015 19:29:34 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC661A1EF4 for ; Tue, 15 Dec 2015 19:29:34 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id u65so26739866qkh.2 for ; Tue, 15 Dec 2015 19:29:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YGfAFhd9h88f1hSmmzj+9jgxj4LRKZAocpYMKS7T8hA=; b=GM2+70M/aA+PCCH7LiM3rOO0xzlFm9GRdgS9anFuZQHMNQreEv3DYGrt5GEzb8jYsd yKKZ0fipbzAtXHSTjhmg6wOAKGH1Z8bKfuyeE+DMCd0uTTg2zoxbReHs4TVpLtJ98I/G mZ6GlnQ9G4n6csHa63WQ4SU/3vOmGC66FacMmhZOAiXnSNkcoDthTJgTaRDhLuS/IJJz 73TkqIK9JI699gM5P14wvgX4ONy8UAqqPOtfbDuwglKda6mx8enV8IBSD63+BpA29FKl 9rnBa6iNbdskG3QBmkzQpPiQycq5Igpf1QtaVCz7dZdRXvUfxKjyCiIrBDEg6LBfgukQ an7w== 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=YGfAFhd9h88f1hSmmzj+9jgxj4LRKZAocpYMKS7T8hA=; b=O53zGh/aeWlOiUaLR0oQk3rTF22fepcNQC/3Hiho8ifdOhASl44hLjOuFnqAzxvUMz FBmE2iE7SDTvwVq5xbDeKIWWPhH6VFVX+rY1/0N4c7EP3N5vEfpZAlAdWQKtdCHoH4GI ZG6h2b6KU4mhHs7x5StShiGLWwobCU5mdwRYN6jSDSPSn6cdKRvgqvOZZxGPMuXz9YEn dpd4p1wNA+9QI9MCe1zROMniYCyLxTBfMSfLIzGXlfsJ+rwQo7t/9gAsvfjLs3+EbBr/ e2PKsEh9z0ok2Gd6bunnCWjWjoOx7P96zEuYX6BS8NET0JwlT2bfr1H+3MAyRkTpIV1R H7Uw== X-Gm-Message-State: ALoCoQni2H7T6GqEclDkffs4NEeN0DQb7YkWygb4pVi3RvU9AsW50+JMXZA4XlKnAT+B9jh6lMgJcug7nLNOcICV81AwKm4MuA== X-Received: by 10.13.218.198 with SMTP id c189mr25420519ywe.165.1450236573249; Tue, 15 Dec 2015 19:29:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 15 Dec 2015 19:28:53 -0800 (PST) In-Reply-To: <5670B774.5050605@streamsec.se> References: <6674a4ec51fe4e158929bf429260d6ea@XCH-RTP-006.cisco.com> <5670AB96.9000602@streamsec.se> <5670B774.5050605@streamsec.se> From: Eric Rescorla Date: Tue, 15 Dec 2015 19:28:53 -0800 Message-ID: To: =?UTF-8?Q?Henrick_Hellstr=C3=B6m?= Content-Type: multipart/alternative; boundary=94eb2c08192aca24720526fb838b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 03:29:36 -0000 --94eb2c08192aca24720526fb838b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 15, 2015 at 4:59 PM, Henrick Hellstr=C3=B6m wrote: > On 2015-12-16 01:31, Watson Ladd wrote: > >> You don't understand the issue. The issue is PRP not colliding, whereas >> PRF can. >> > > Oh, but I concur. This means that if you observe two same valued cipher > text blocks, you know that the corresponding key stream blocks can't be > identical, That assumes that the plaintext is identical, no? That may be true in some limited cases, but isn't generally true -Ekr and deduce that the corresponding plain text blocks have to be different. > Such observations consequently leak information about the plain text, in > the rare and unlikely event they actually occur. > > However, calling it an exploitable weakness is a bit of a stretch. AES-CB= C > is likely to loose confidentiality slightly faster, for typical plain tex= ts. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c08192aca24720526fb838b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 15, 2015 at 4:59 PM, Henrick Hellstr=C3=B6m <henrick@st= reamsec.se> wrote:
On 2015-12-16 01:31, Watson Ladd wrote:
You don't understand the issue. The issue is PRP not colliding, whereas=
PRF can.

 Oh, but I concur. This means that if you observe two same valued cipher tex= t blocks, you know that the corresponding key stream blocks can't be id= entical,

That assumes that the plaintext i= s identical, no? That may be true in some limited
cases, but isn&= #39;t generally true

-Ekr

and deduce that the corresponding plain text blo= cks have to be different. Such observations consequently leak information a= bout the plain text, in the rare and unlikely event they actually occur.
However, calling it an exploitable weakness is a bit of a stretch. AES-CBC = is likely to loose confidentiality slightly faster, for typical plain texts= .


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

--94eb2c08192aca24720526fb838b-- From nobody Tue Dec 15 19:36:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DAC1A21B2 for ; Tue, 15 Dec 2015 19:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, 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 7O1MAuM9lJIL for ; Tue, 15 Dec 2015 19:36:02 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4533B1A21A9 for ; Tue, 15 Dec 2015 19:36:02 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id k189so46157811qkc.0 for ; Tue, 15 Dec 2015 19:36:02 -0800 (PST) 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=gWtqSgwCnSKYtlDs0r/GfZ4IaWCZXf9D7SHxQPs6ivw=; b=ceo8MvQkQROVlAllwcxcri67dSH0ROZT0aNAketND7ESFDdLnsH5F3fpQuaOQ1J7LT 45hCO06TKUGHX37e7mfhZ8ZiNoUSBLei3IsPuWmzoAmCruxxYFRYYPbtZ85ebalTw3ym Axi8QH0EzZoSv7dzgHUg/qJ5954/95grUdzOvNIiXApNZDVcUoXsWufhkgbAJmNKLivb aFBKi1u3/ksp40/RBR++UAja5S0p89DHbDOyrQ1Cdo1ixTysMNKVeRHNi/h2vegLJDbO 6AFFJYiuZTl/Fr0aCWnX6T3yziIuRPbWCO+v5311T2t2MHjHd/7sdFGwsTK2ZXtczFoq dHaQ== MIME-Version: 1.0 X-Received: by 10.13.229.71 with SMTP id o68mr26771894ywe.326.1450236961468; Tue, 15 Dec 2015 19:36:01 -0800 (PST) Received: by 10.129.148.131 with HTTP; Tue, 15 Dec 2015 19:36:01 -0800 (PST) In-Reply-To: <5670B774.5050605@streamsec.se> References: <6674a4ec51fe4e158929bf429260d6ea@XCH-RTP-006.cisco.com> <5670AB96.9000602@streamsec.se> <5670B774.5050605@streamsec.se> Date: Tue, 15 Dec 2015 22:36:01 -0500 Message-ID: From: Watson Ladd To: =?UTF-8?Q?Henrick_Hellstr=C3=B6m?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 03:36:03 -0000 On Tue, Dec 15, 2015 at 7:59 PM, Henrick Hellstr=C3=B6m wrote: > On 2015-12-16 01:31, Watson Ladd wrote: >> >> You don't understand the issue. The issue is PRP not colliding, whereas >> PRF can. > > > Oh, but I concur. This means that if you observe two same valued cipher t= ext > blocks, you know that the corresponding key stream blocks can't be > identical, and deduce that the corresponding plain text blocks have to be > different. Such observations consequently leak information about the plai= n > text, in the rare and unlikely event they actually occur. > > However, calling it an exploitable weakness is a bit of a stretch. AES-CB= C > is likely to loose confidentiality slightly faster, for typical plain tex= ts. The problem is that once you stack enough of those negligible probabilities together, you end up with something big. Push up to 2^{63} bytes, and the collision probability is 1/4 or 1/2 (I didn't recompute it just now). And while the definition seems to involve only a minor loss of security, that's the definition people use for security. Using 2^{-64} as a success probability ensures that attackers who can exploit multiple connections are still defended against. Could we do better with 2^{-32}? Sure. But at this point we're saying you can transport over 16 Gbyte of data before rekeying: I think that's enough for almost all purposes. --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Dec 15 19:42:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02571A6EED for ; Tue, 15 Dec 2015 19:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 1ZQtsY-6HRqi for ; Tue, 15 Dec 2015 19:42:51 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99BA1A6EE9 for ; Tue, 15 Dec 2015 19:42:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0AE56BE55; Wed, 16 Dec 2015 03:42:49 +0000 (GMT) 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 djZA5Vb5Fz_o; Wed, 16 Dec 2015 03:42:48 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.31.96]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 79E03BE51; Wed, 16 Dec 2015 03:42:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450237368; bh=s5eCIhkAxisEpe3pwhJoIR1qNXxN9poF+FgPDSpvVbk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Zx9I1xAQHLVRtBj1ZuTkpKR8jZ8UvaGlY84/EYQkmtEUXSvpYzC6NjFCO35HcC+Eb y83tZJ+jf8K2zrWrbyS7vOn9IYimJMjwMH92Fysh+LvbH/LJwOjaVXKQyvB23gesij O0z5U+XvlmuvMdKsLEVy2yDl4Ec3nAgQsiaYNhOo= To: Watson Ladd , =?UTF-8?Q?Henrick_Hellstr=c3=b6m?= References: <6674a4ec51fe4e158929bf429260d6ea@XCH-RTP-006.cisco.com> <5670AB96.9000602@streamsec.se> <5670B774.5050605@streamsec.se> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5670DDB7.5020809@cs.tcd.ie> Date: Wed, 16 Dec 2015 03:42:47 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 03:42:52 -0000 Hi Watson, On 16/12/15 03:36, Watson Ladd wrote: > The problem is that once you stack enough of those negligible > probabilities together, you end up with something big. Push up to > 2^{63} bytes, and the collision probability is 1/4 or 1/2 (I didn't > recompute it just now). The collision probability of... what? (For that to be 0.50 my gut tells me it's something that's really not at all likely to be worrisome, but I know I'm not expert here hence me asking:-) Thanks, S. From nobody Tue Dec 15 19:57:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81ABA1A6F30 for ; Tue, 15 Dec 2015 19:57:05 -0800 (PST) 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 aUaTBWj2Gmxl for ; Tue, 15 Dec 2015 19:57:04 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482191A6EFB for ; Tue, 15 Dec 2015 19:57:04 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id u65so27391449qkh.2 for ; Tue, 15 Dec 2015 19:57:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=CByVqD7GOcTvc848Wyn468GcRTsGIH4vbHb5HBwDAA4=; b=w0z3SvboKs6RshcRklyztzozHG4Zo6ajamLWaSg+vEb+r59WnIRmjJG33idk9c+rDz +u3J7bUWpnyeUd3jDrbDMVb5hfug7/i+vR2r9DIc3n3MOOBgqIsAMgOIT3qkp89TTHqw 5fNe39V9jdjvXrvKADzqcrUR0a9m726JRsSd0jLOU41Xbuwv/Es0WZO3aZO3x+VBfyvY QrzohAwLyBsqr8HfYRjaUpg2gL4ITf2ujjGJsRQCoqmEicYHwp8nlgLm5jvTwEwzCmy4 ydMsi0+uoDLOtYgEH4P83chH9r2zU2N8rxuqZKTF6LbbN+0PLMEYU4lJRFqP2dgSJ2ei N3Og== X-Received: by 10.55.79.207 with SMTP id d198mr53367199qkb.49.1450238223495; Tue, 15 Dec 2015 19:57:03 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id j36sm1878542qgd.46.2015.12.15.19.57.02 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 15 Dec 2015 19:57:02 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Tue, 15 Dec 2015 22:57:01 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201512152257.01966.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 03:57:05 -0000 On Tuesday, December 15, 2015 09:40:41 pm Martin Thomson wrote: > In light of that, the actual limits don't matter that much to me. As > David McGrew suggested, set a limit at 2^32 and avoid having to think > too hard about how close to the failure point you might be. +1 In fact, if we're OK with setting this rather low threshold, then we could even get rid of the rekey signal entirely and just have an automatic rekey after every 4GiB for all ciphers. That'd be one less complexity to deal with. Rekeys would be routine. Dave From nobody Tue Dec 15 19:59:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA6C1A6F71 for ; Tue, 15 Dec 2015 19:59:37 -0800 (PST) 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 OG1cXIU5e9wF for ; Tue, 15 Dec 2015 19:59:36 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FEF61A6F38 for ; Tue, 15 Dec 2015 19:59:36 -0800 (PST) Received: by mail-ig0-x232.google.com with SMTP id to18so31322264igc.0 for ; Tue, 15 Dec 2015 19:59:36 -0800 (PST) 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=htXwDfPIetXFXUDO2UkZW6fsyNNdVqeqnQrbnpwgzOU=; b=SlzkeurFTQjZC+rvDuBzRPsK2RsC3hezNKu9LMDD2eTuFJR5puVLSr0jIB9YdOz9Xg 3Mhz6r1A15Vywedz+UEnDntWzupMKnxcqtq9AMk4Vnn0+nDv84xwN0RCpzFnyq6utxBu WTK1BoSenYkmsLhQKYFP645Uy51TRtRztg2DnpKiMDUkpHjLToq8bB5CFWNVfM7rxG9S DEq+wRw/VpjeYNpqpzJA+Hs2m38g39jwqiscahFGzSPefgro5qcTZh14wI0EZ1V/ei/V PgnjWV1dPparbUoVtuUHkyrRNMih8uj8fRp8k+J264jIDMIlRCuBeI2sEXAp8mmg6sQn TAcA== MIME-Version: 1.0 X-Received: by 10.107.169.29 with SMTP id s29mr40738644ioe.190.1450238375657; Tue, 15 Dec 2015 19:59:35 -0800 (PST) Received: by 10.36.149.130 with HTTP; Tue, 15 Dec 2015 19:59:35 -0800 (PST) In-Reply-To: <201512152257.01966.davemgarrett@gmail.com> References: <201512152257.01966.davemgarrett@gmail.com> Date: Wed, 16 Dec 2015 14:59:35 +1100 Message-ID: From: Martin Thomson To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 03:59:37 -0000 On 16 December 2015 at 14:57, Dave Garrett wrote: > In fact, if we're OK with setting this rather low threshold, then we could even get rid of the rekey signal entirely and just have an automatic rekey after every 4GiB for all ciphers. That'd be one less complexity to deal with. Rekeys would be routine. I don't like automatic rekey (though I almost like the per-record rekeying that I think was semi-facetiously suggested by someone). An explicit rekey allows for two things: - testing - reducing the limit if we find that the cipher is more busted than we originally thought (with respect to key overuse) From nobody Tue Dec 15 20:02:12 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928CC1A6F80 for ; Tue, 15 Dec 2015 20:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 yswXsqkJRUKn for ; Tue, 15 Dec 2015 20:02:09 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 29F891A6F82 for ; Tue, 15 Dec 2015 20:02:09 -0800 (PST) Received: from [173.75.83.132] (helo=Williams-MacBook-Pro.local) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1a93Hw-0001TA-85 for tls@ietf.org; Tue, 15 Dec 2015 23:02:04 -0500 Date: Tue, 15 Dec 2015 20:01:58 -0800 From: Bill Frantz To: tls@ietf.org X-Priority: 3 In-Reply-To: <5670DDB7.5020809@cs.tcd.ie> 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7985c10378a241431b7a615688ece6093c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.132 Archived-At: Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 04:02:10 -0000 So we have to trade off the risks of too much data vs. the risks=20 of a complex rekey protocol vs. the risks having the big data=20 applications build new connections every 2**36 or so bytes. If we don't have rekeying, then the big data applications are=20 the only ones at risk. If we do, it may be a wedge which can=20 compromise all users. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Re: Hardware Management Modes: | Periwinkle (408)356-8506 | If there's a mode, there's a | 16345=20 Englewood Ave www.pwpconsult.com | failure mode. - Jerry Leichter | Los Gatos,=20 CA 95032 From nobody Tue Dec 15 20:02:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA401A6F7A for ; Tue, 15 Dec 2015 20:02:22 -0800 (PST) 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, HTML_MESSAGE=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 7TZhttbceqJ0 for ; Tue, 15 Dec 2015 20:02:21 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823E91A6F8F for ; Tue, 15 Dec 2015 20:02:21 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id t125so46629093qkh.3 for ; Tue, 15 Dec 2015 20:02:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WGdrKda8Dv2a7PjOoGjEtrhzshQfU7ZQ+PANjcSiG3Q=; b=hKRt4XexFpXx7qZ76pkt54f62eOVt3T/02a/yGSQ7zUP/ooC/UlI+DHRrqMP4/MK4b rJx5FmXBWSAXNdaNKbHvTHGQJdumN8hGNfcyzeSXqtg7m2nYhbu4GhQYdhMzcRTJiU84 HyEFZWY+LwmWiYmCl2gTxC87AAOxlbzzDwk4r+kdo30QTImk8JtGQh0+ywr0ffHY+nIA VbVGpiMMQ7MbqM8Xuj3/rJHeGFV1HVEPn3V71DMB5QaAua7Aqc2oV75nrNJXS3HlikqE yh9uQizNw7h6Uokqy6ITeT0CJtrKZDkXKZ6MU7UjfYoZjdXKvfR8Mv+ZShaS/5P0mbIP 8R6g== 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=WGdrKda8Dv2a7PjOoGjEtrhzshQfU7ZQ+PANjcSiG3Q=; b=Q9/Ar8cK4ldJzVw84//gb7Q1X8BxsNI3xH9xG3wV20eSrGC4NdiEY660m69FibKeYw f2OwjQeTtew2MhRW2qLWKq3KP53UTv7k1SfmpSKNzIxdOjP9d/ov0yGhiYaEfZWDF48n E4S0dlM6OvNFkeDiRl/KFcP1+HguBSykoLvwtgUJmpPI5DgrJSSUwMH6CG9fgSefKUoX Z4mGNAsD5krJR9l6yDBs7R7LbhEuHX/pECu2qdhoVq1gSDdXRVfWZNh1rxEhvyWXXktd PTwpFiLeoYDwAtHBKxque9XLInUuuLHZPOSyOt2VLaK30hCBANS+vSCU9+1amlUuVq5Z l9WQ== X-Gm-Message-State: ALoCoQk6+oZza+micqIeqeTUTLGGKzlH0G8moazgg1wQCIOKjJaxLWLtQpF6mumoGQ54tvF4ctcEjj+q+YcQGMLQiaWim2MW3A== X-Received: by 10.13.193.4 with SMTP id c4mr11122389ywd.192.1450238540590; Tue, 15 Dec 2015 20:02:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 15 Dec 2015 20:01:41 -0800 (PST) In-Reply-To: References: <201512152257.01966.davemgarrett@gmail.com> From: Eric Rescorla Date: Tue, 15 Dec 2015 20:01:41 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114caa9e0d683f0526fbf971 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 04:02:22 -0000 --001a114caa9e0d683f0526fbf971 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 15, 2015 at 7:59 PM, Martin Thomson wrote: > On 16 December 2015 at 14:57, Dave Garrett wrote: > > In fact, if we're OK with setting this rather low threshold, then we > could even get rid of the rekey signal entirely and just have an automatic > rekey after every 4GiB for all ciphers. That'd be one less complexity to > deal with. Rekeys would be routine. > > I don't like automatic rekey (though I almost like the per-record > rekeying that I think was semi-facetiously suggested by someone). An > explicit rekey allows for two things: > - testing > - reducing the limit if we find that the cipher is more busted than > we originally thought (with respect to key overuse) > Also, allows each side to have their own opinion. Not a fan of automatic rekey. -Ekr --001a114caa9e0d683f0526fbf971 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 15, 2015 at 7:59 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On= 16 December 2015 at 14:57, Dave Garrett <davemgarrett@gmail.com> wrote:
> In fact, if we're OK with setting this rather low threshold, then = we could even get rid of the rekey signal entirely and just have an automat= ic rekey after every 4GiB for all ciphers. That'd be one less complexit= y to deal with. Rekeys would be routine.

I don't like automatic rekey (though I almost like the per-recor= d
rekeying that I think was semi-facetiously suggested by someone).=C2=A0 An<= br> explicit rekey allows for two things:
=C2=A0- testing
=C2=A0- reducing the limit if we find that the cipher is more busted than we originally thought (with respect to key overuse)
Also, allows each side to have their own opinion.
Not a fan of automatic rekey.

-Ekr
=C2=A0

--001a114caa9e0d683f0526fbf971-- From nobody Tue Dec 15 20:08:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391501A6F49 for ; Tue, 15 Dec 2015 20:08:12 -0800 (PST) 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 muniTYX3mfsA for ; Tue, 15 Dec 2015 20:08:11 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1F881A6F33 for ; Tue, 15 Dec 2015 20:08:10 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id u65so27663102qkh.2 for ; Tue, 15 Dec 2015 20:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=mPS23csBkbuEWoQH1DzNr7hwqafUtyTW6ZPm/TIpp5M=; b=DjcI8fWrwR51Ql6/ziRfcNMVr3A9ToSPRKZMCN2/1OJ2PBnUftnWAe4TPRu2s75LdX zPts7rhcGa/a6UeaTdAElAOnuZJyB11qsKm37Py9U3YA3ZgvUZ3YNw9WRGFEJaMLecRf t4B5HeDVlfMgPDQ9vlzWmypjeiVI7CzUB64WertCSdapPS6+hSeDyQf2WtKiMCdnsCQm 4Y9D+dI026C63YLnPdCbKc32hATPwWY+erlSXWLax1vNKgJ1/U5+8rtxinf1EP9bz76x HnBlN0UQ+j+4F+7VxA1f399tY48/ypfwJTHluci6AwasSvrStWDTlsmx1dmqwuErYTFj TIKw== X-Received: by 10.55.72.140 with SMTP id v134mr22351769qka.24.1450238890094; Tue, 15 Dec 2015 20:08:10 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id d69sm1893588qkb.45.2015.12.15.20.08.09 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 15 Dec 2015 20:08:09 -0800 (PST) From: Dave Garrett To: Martin Thomson , Eric Rescorla Date: Tue, 15 Dec 2015 23:08:08 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201512152257.01966.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201512152308.08667.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 04:08:12 -0000 On Tuesday, December 15, 2015 10:59:35 pm Martin Thomson wrote: > On 16 December 2015 at 14:57, Dave Garrett wrote: > > In fact, if we're OK with setting this rather low threshold, then we could even get rid of the rekey signal entirely and just have an automatic rekey after every 4GiB for all ciphers. That'd be one less complexity to deal with. Rekeys would be routine. > > I don't like automatic rekey (though I almost like the per-record > rekeying that I think was semi-facetiously suggested by someone). An > explicit rekey allows for two things: > - testing > - reducing the limit if we find that the cipher is more busted than > we originally thought (with respect to key overuse) On Tuesday, December 15, 2015 11:01:41 pm Eric Rescorla wrote: > On Tue, Dec 15, 2015 at 7:59 PM, Martin Thomson > wrote: > Also, allows each side to have their own opinion. We could just make the threshold a configurable parameter, with default/maximum at 2^32 bytes. Each endpoint could just provide its threshold in a new extension. Both get to specify what they want and it could be lowered arbitrarily for testing or panic fix. Dave From nobody Tue Dec 15 20:11:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0651A6F9E for ; Tue, 15 Dec 2015 20:11:38 -0800 (PST) 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 D6PaDdRAWgq4 for ; Tue, 15 Dec 2015 20:11:37 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375F31A6F33 for ; Tue, 15 Dec 2015 20:11:37 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id ph11so126131515igc.1 for ; Tue, 15 Dec 2015 20:11:37 -0800 (PST) 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=J7OpOvwj+De6ZXuctNB8VA3J5mmRYPfrvxAzTOIWM3I=; b=bBsCf0iAiO3OQ7DcLboarxx28C3aYXTeFegIo2RC4lKqyMDEdbvg8KjMt593BjmAZH zpNpvZYjh2D7OyxUrLlEgqpRvSMdthp7AariEgaoShoRxT9wta7ZwACmdw6o5erHRQ5u svVmdBSsFUOwrSnm7lqca1N4Y+SxXeh1M9S9ACtwGYKOgMqFfWqOEhjoPSJe9FAb0e3p mQouJM9ZpuZ1W0BmLaC4X7uSlFhQjgO/QmME9VwdALjJ2BKfks5vCC8dOlqhvgrsoue7 RAmJnf94mudaQT0TNW6SJff2bbVc+a80qcB7Gjnf9d8TDCcyGVGw5rhsJZPbl6OTkDDs Jhxg== MIME-Version: 1.0 X-Received: by 10.107.26.144 with SMTP id a138mr40156213ioa.100.1450239096600; Tue, 15 Dec 2015 20:11:36 -0800 (PST) Received: by 10.36.149.130 with HTTP; Tue, 15 Dec 2015 20:11:36 -0800 (PST) In-Reply-To: <201512152308.08667.davemgarrett@gmail.com> References: <201512152257.01966.davemgarrett@gmail.com> <201512152308.08667.davemgarrett@gmail.com> Date: Wed, 16 Dec 2015 15:11:36 +1100 Message-ID: From: Martin Thomson To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 04:11:38 -0000 On 16 December 2015 at 15:08, Dave Garrett wrote: > We could just make the threshold a configurable parameter, with default/m= aximum at 2^32 bytes. Each endpoint could just provide its threshold in a n= ew extension. Both get to specify what they want and it could be lowered ar= bitrarily for testing or panic fix. That sounds more complex than the current option. From nobody Tue Dec 15 20:19:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BD21A6FBC for ; Tue, 15 Dec 2015 20:19:17 -0800 (PST) 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 CDJO3aysxcIC for ; Tue, 15 Dec 2015 20:19:16 -0800 (PST) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3134D1A6F82 for ; Tue, 15 Dec 2015 20:19:16 -0800 (PST) Received: by mail-qg0-x236.google.com with SMTP id 21so25516230qgx.1 for ; Tue, 15 Dec 2015 20:19:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=TFqV+ltUlGPiZS07ExuwmmGD9ImS5KXz5uTyW/PQXtk=; b=oJ+eHGQvmndheamkqGzeQ6anMySiBnEQhkyBG5oOqImkPYuD+Q56JCzYg3r5O6Lrc3 8YHP7I6kAnP2akbMqV03eBYetAVqu2Pot3GKr3JhM2OEO2NCn0SVR7nNXnJOV3Eq1399 5v6DdCSNFqpnMkof0swPa1flx80mHRozJp5MNk2bMiNTXzsFMPUjHsfFMNuIJRXDm+6I HB7TtghDbdSammEEmychZz4Eyi9A0CTmHmFCGChxvN2/0RaFfzEjnnRdGsyGVYwraHVE FfZRBt+zICJRTtj1EtqanjnnBf8xO2Fi4DZ33SwcqUHfOiQDfhqURcJ4K2z1bUWrm6xp 5KeQ== X-Received: by 10.140.18.199 with SMTP id 65mr56368216qgf.10.1450239555293; Tue, 15 Dec 2015 20:19:15 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id e10sm1931807qka.1.2015.12.15.20.19.14 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 15 Dec 2015 20:19:14 -0800 (PST) From: Dave Garrett To: Martin Thomson Date: Tue, 15 Dec 2015 23:19:13 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201512152308.08667.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201512152319.13902.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 04:19:17 -0000 On Tuesday, December 15, 2015 11:11:36 pm Martin Thomson wrote: > On 16 December 2015 at 15:08, Dave Garrett wrote: > > We could just make the threshold a configurable parameter, with default/maximum at 2^32 bytes. Each endpoint could just provide its threshold in a new extension. Both get to specify what they want and it could be lowered arbitrarily for testing or panic fix. > > That sounds more complex than the current option. It's the difference between one signal in the handshake followed by predictable rekeying and an arbitrary number of signals at arbitrary points after the handshake. Dave From nobody Tue Dec 15 22:39:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09AD1A87D4 for ; Tue, 15 Dec 2015 22:39:14 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 BVEki5Rx4BIr for ; Tue, 15 Dec 2015 22:39:12 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB27F1A87D1 for ; Tue, 15 Dec 2015 22:39:11 -0800 (PST) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-08v.sys.comcast.net with comcast id u6fB1r00356HXL0016fB4n; Wed, 16 Dec 2015 06:39:11 +0000 Received: from [192.168.1.2] ([73.170.34.26]) by resomta-po-12v.sys.comcast.net with comcast id u6fA1r0020ZpzqZ016fAk8; Wed, 16 Dec 2015 06:39:10 +0000 Message-ID: <5671070E.7010800@brainhub.org> Date: Tue, 15 Dec 2015 22:39:10 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: tls@ietf.org References: <6674a4ec51fe4e158929bf429260d6ea@XCH-RTP-006.cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000503050503080103040503" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1450247951; bh=Zl00faB4fOYN2a1wp/bYW+rUaLpRAf4+FdUC2GFgL1o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=wDYJgMmXP61eeGNUcqQhbzCNzSZlZRJncWPGAsPagtan5tZePdGTALHvYXSVExEVE PbRWyiFL9xS56ZtJusVHdm4Jtjx3GBvCqDWnVyKeY5ns+g2a918RM9fp000C96Tn2m /8via/+gVlt2W6tTBj0Rh2GONYPGJenUijYHBacT8uV/rzkYsMUK6+5+ryTy0SV2kY sYQP3VYyEM5OEPl0jegJG8XJpCYlpM1HDrNzZGSFVtn/R488mhrivqf3kNvGsoiOFD GeMoYSjqIj/ARWcDRbiswZNKXfMiX7hsf+ysbQjoBoHMOocRw7xVKpuP8L2LqZCvWO +0vtRiWcrx6fg== Archived-At: Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 06:39:15 -0000 This is a multi-part message in MIME format. --------------000503050503080103040503 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 12/15/2015 03:47 PM, Watson Ladd wrote: > > > On Dec 15, 2015 6:08 PM, "Scott Fluhrer (sfluhrer)" > > wrote: > > > > > > > > > -----Original Message----- > > > From: Watson Ladd [mailto:watsonbladd@gmail.com > ] > > > Sent: Tuesday, December 15, 2015 5:38 PM > > > To: Scott Fluhrer (sfluhrer) > > > Cc: Eric Rescorla; tls@ietf.org > > > Subject: Re: [TLS] Data volume limits > > > > > > On Tue, Dec 15, 2015 at 5:01 PM, Scott Fluhrer (sfluhrer) > > > > wrote: > > > > Might I enquire about the cryptographical reason behind such a > limit? > > > > > > > > > > > > > > > > Is this the limit on the size of a single record? GCM does have a > > > > limit approximately there on the size of a single plaintext it can > > > > encrypt. For TLS, it encrypts a record as a single plaintext, > and so > > > > this would apply to extremely huge records. > > > > > > The issue is the bounds in Iwata-Ohashai-Minematsu's paper, which > show a > > > quadratic confidentiality loss after a total volume sent. This is > an exploitable > > > issue. > > > > Actually, the main result of that paper was that GCM with nonces > other than 96 bits were less secure than previous thought (or, rather, > that the previous proofs were wrong, and what they can prove is > considerably worse; whether their proof is tight is an open > question). They address 96 bit nonces as well, however the results > they get are effectively unchanged from the original GCM paper. I had > thought that TLS used 96 bit nonces (constructed from 32 bit salt and > a 64 bit counter); were the security guarantees from the original > paper too weak? If not, what has changed? > > > > The quadratic behavior in the security proofs are there for just > about any block cipher mode, and is the reason why you want to stay > well below the birthday bound. However, that's as true for (say) CBC > mode as it is for GCM > > That's correct. And when we crunch the numbers assuming 2^60 is > negligible out comes 2^36 bytes. This doesn't hold for ChaCha20. > If 2^36 above is about confidentiality, I am getting q<2^34, assuming probability of a collision lower than p=2^-60. 2^34*(2^34-1) < (2^(128-60))/0.316 (that's the formula with 'e', not C(q,2)). q=2^34 blocks is 2^38 bytes (256 GiB). Close enough, although p=2^-60 could have been higher for higher total bytes before rekey. > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------000503050503080103040503 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 12/15/2015 03:47 PM, Watson Ladd wrote:


On Dec 15, 2015 6:08 PM, "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Watson Ladd [mailto:watsonbladd@gmail.com]
> > Sent: Tuesday, December 15, 2015 5:38 PM
> > To: Scott Fluhrer (sfluhrer)
> > Cc: Eric Rescorla; tls@ietf.org
> > Subject: Re: [TLS] Data volume limits
> >
> > On Tue, Dec 15, 2015 at 5:01 PM, Scott Fluhrer (sfluhrer)
> > <sfluhrer@cisco.com> wrote:
> > > Might I enquire about the cryptographical reason behind such a limit?
> > >
> > >
> > >
> > > Is this the limit on the size of a single record?  GCM does have a
> > > limit approximately there on the size of a single plaintext it can
> > > encrypt.  For TLS, it encrypts a record as a single plaintext, and so
> > > this would apply to extremely huge records.
> >
> > The issue is the bounds in Iwata-Ohashai-Minematsu's paper, which show a
> > quadratic confidentiality loss after a total volume sent. This is an exploitable
> > issue.
>
> Actually, the main result of that paper was that GCM with nonces other than 96 bits were less secure than previous thought (or, rather, that the previous proofs were wrong, and what they can prove is considerably worse; whether their proof is tight is an open question).  They address 96 bit nonces as well, however the results they get are effectively unchanged from the original GCM paper.  I had thought that TLS used 96 bit nonces (constructed from 32 bit salt and a 64 bit counter); were the security guarantees from the original paper too weak?  If not, what has changed?
>
> The quadratic behavior in the security proofs are there for just about any block cipher mode, and is the reason why you want to stay well below the birthday bound.  However, that's as true for (say) CBC mode as it is for GCM

That's correct. And when we crunch the numbers assuming 2^60 is negligible out comes 2^36 bytes. This doesn't hold for ChaCha20.


If 2^36 above is about confidentiality, I am getting q<2^34, assuming probability of a collision lower than p=2^-60.

2^34*(2^34-1) <  (2^(128-60))/0.316 (that's the formula with 'e', not C(q,2)).

q=2^34 blocks is 2^38 bytes (256 GiB). Close enough, although p=2^-60 could have been higher for higher total bytes before rekey.


>



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

--------------000503050503080103040503-- From nobody Tue Dec 15 23:37:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566351A8A93 for ; Tue, 15 Dec 2015 23:37:41 -0800 (PST) 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 ByeXrjb9TQLD for ; Tue, 15 Dec 2015 23:37:40 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053121A8A4D for ; Tue, 15 Dec 2015 23:37:40 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id n186so197446605wmn.1 for ; Tue, 15 Dec 2015 23:37:39 -0800 (PST) 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=9RUzkixCi2XfuOzCboWmz7jT+0eDKOc2dtIGaGNSKM0=; b=08j89ZZqqKHKHk1v9c9G0ktseoqZZqOjuZ35fnhaFRS8A7fn0H44mODyCPTsKQOeWR 6eEbkwBaAq3gqEO85PX9mrAO/DMMkafSmgK6axk3fk4bJNgphsn569/SckFUSKkZKV7w MCZakwKvb6JMSZcaytFaskczdzHFqzEbGvv+l3MCpiVY8d6SbQqfhzySXtQwEMGD80D5 VPgWg7I7qShtoBQw/tOHT6J2sVveT6VxluukY1hyr6kKgRcuxb1E3W/pzWki636TOEjI tgdUcyseMNWuwG+p6WuWNFqBN0i7y1ti6gQZ4SPEdmRDkONywM0yzU+XLWsw20o7nXty oXxQ== X-Received: by 10.194.112.131 with SMTP id iq3mr48839769wjb.35.1450251458668; Tue, 15 Dec 2015 23:37:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.15.229 with HTTP; Tue, 15 Dec 2015 23:36:58 -0800 (PST) From: Ryan Carboni Date: Tue, 15 Dec 2015 23:36:58 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1130d350076f5b0526fefbf6 Archived-At: Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 07:37:41 -0000 --001a1130d350076f5b0526fefbf6 Content-Type: text/plain; charset=UTF-8 How often does TLS rekey anyway? I know RC4 rekeys per packet, but I've read and searched a fair amount of documentation, and haven't found anything on the subject. Perhaps I'm looking for the wrong terms or through the wrong documents. --001a1130d350076f5b0526fefbf6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How often does TLS rekey anyway? I know RC4 rekeys per pac= ket, but I've read and searched a fair amount of documentation, and hav= en't found anything on the subject. Perhaps I'm looking for the wro= ng terms or through the wrong documents.
--001a1130d350076f5b0526fefbf6-- From nobody Tue Dec 15 23:46:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15D11A8AFD for ; Tue, 15 Dec 2015 23:46:15 -0800 (PST) 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, 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 c4EHx_7-gLTW for ; Tue, 15 Dec 2015 23:46:12 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0602.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::602]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB051A8ADC for ; Tue, 15 Dec 2015 23:46:12 -0800 (PST) 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.1.337.19; Wed, 16 Dec 2015 07:45:53 +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.01.0337.024; Wed, 16 Dec 2015 07:45:53 +0000 From: "Paterson, Kenny" To: Ryan Carboni Thread-Topic: [TLS] Data volume limits Thread-Index: AQHRN9SL6qaFMoZQh068EoUf5LXa7J7NO+ui Date: Wed, 16 Dec 2015 07:45:53 +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: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-originating-ip: [202.214.65.72] x-microsoft-exchange-diagnostics: 1; DBXPR03MB384; 5:ul3ItHGx/Lju0cQ6hhFT+bYVWuw4esugmCYzacooR/GyQXKENGUwNvtGdlRVJaBj6MSzhbaOVjXwQHu71+ElE8n8zCtxVzRMWWkonmzZGay1PEvyJIlFzDzVOkFBliHf37Ui+6VdsvyFeDaPaCxcIg==; 24:LsksN7aOVbtjriTEXieCGLFq8FE1GlEXDN+jg8II9S+0I9y3TlNEe/7ppDIXJZrwa0FRhtx68iz0fnxzbzZUxxbDn4hws/1ifXeO6dbgnHs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB384; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:DBXPR03MB384; BCL:0; PCL:0; RULEID:; SRVR:DBXPR03MB384; x-forefront-prvs: 0792DBEAD0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(199003)(189002)(189998001)(74482002)(86362001)(33656002)(1411001)(87936001)(19580405001)(82746002)(19580395003)(66066001)(83716003)(101416001)(92566002)(122556002)(40100003)(105586002)(50986999)(5002640100001)(11100500001)(10400500002)(81156007)(36756003)(5008740100001)(97736004)(5004730100002)(110136002)(5001960100002)(106356001)(54356999)(6116002)(3846002)(102836003)(76176999)(15975445007)(2900100001)(2950100001)(586003)(77096005)(1220700001)(1096002)(106116001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB384; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2015 07:45:53.5270 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB384 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 07:46:16 -0000 RC4 does not rekey per application layer fragment in TLS. The same key is u= sed for the duration of a connection.=20 Other protocols using RC4 do rekey per packet, eg WEP and WPA/TKIP.=20 Cheers Kenny > On 16 Dec 2015, at 16:37, Ryan Carboni wrote: >=20 > How often does TLS rekey anyway? I know RC4 rekeys per packet, but I've r= ead and searched a fair amount of documentation, and haven't found anything= on the subject. Perhaps I'm looking for the wrong terms or through the wro= ng documents. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Dec 16 00:44:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020961A7025 for ; Wed, 16 Dec 2015 00:44:53 -0800 (PST) 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 QymABl3KNJ2S for ; Wed, 16 Dec 2015 00:44:51 -0800 (PST) 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 4A9361A8A65 for ; Wed, 16 Dec 2015 00:44:49 -0800 (PST) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tBG8iJGP015700 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 16 Dec 2015 09:44:20 +0100 From: Simon Josefsson To: Eric Rescorla References: OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151216:tls@ietf.org::GFdtvuu0jcdlbUgF:3ITA X-Hashcash: 1:22:151216:ekr@rtfm.com::r4fQGmvleDGjlsf5:bkYd Date: Wed, 16 Dec 2015 09:44:18 +0100 In-Reply-To: (Eric Rescorla's message of "Tue, 15 Dec 2015 13:14:30 -0800") Message-ID: <87twnibx5p.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (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.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 08:44:53 -0000 --=-=-= Content-Type: text/plain Eric Rescorla writes: > Watson kindly prepared some text that described the limits on what's safe > for AES-GCM and restricting all algorithms with TLS 1.3 to that lower > limit (2^{36} bytes), even though ChaCha doesn't have the same > restriction. Can we see a brief writeup explaining the 2^36 number? I don't like re-keying. It is usually a sign that your primitives are too weak and you are attempting to hide that fact. To me, it is similar to discard the first X byte of RC4 output. If AES-GCM cannot provide confidentiality beyond 64GB (which would surprise me somewhat), I believe we ought to be careful about recommending it. Of course, the devil is in the details: if the risk is that the secret key is leaked, that's fatal; if the risk is that the attacker can tell whether two particular plaintext 128 byte blocks are the same or not in the entire file, that can be a risk we can live with (similar to the discard X bytes of RC4 fix). I believe 64GB is within the range that people download in a web browser these days. More data intensive longer-running protocols often transfer significantly more. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWcSRiAAoJEIYLf7sy+BGdOjQH/iXuDhlGyN521aYbhlhoHYVJ 2juNU60u7x5ueUUn+UxRrvXiNKO1ZFdUdFwpE/lmSGhYpQCUSbLqqo2TS+AgTiOU f4PfNnaZV/JrK+0fad0+9kHbAWyllreC1LOuUcQGWZjH9gyhecsncYZ1QeXlRksx 4ywsPAp9FbakGIhWCOHCgPmMCIFAq0f0G7kHFeI02ehhdx0rmEdnLApivxUc3xud cbrCqvR7UxB4DgRffgxQvp0pj84RKUGj97O1vZLvTy0yzLgcPDiJBw9lkVDtTB4y wTCimv2TSc/IE3C7EaNnje65/9/JP7zgXJOTjAKAEVea9I7uRsoMgeW9dwLwa18= =/Ckr -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 16 03:18:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057571A8AA8 for ; Wed, 16 Dec 2015 03:18:39 -0800 (PST) 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, HTML_MESSAGE=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 DfKiXdV28PJI for ; Wed, 16 Dec 2015 03:18:37 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E371A8A54 for ; Wed, 16 Dec 2015 03:18:36 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id k189so58070255qkc.0 for ; Wed, 16 Dec 2015 03:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4YG03gU0ZRJ6QL99ZRJIvBzFkeqE35J4RARqeAWO3xY=; b=kOdM9M3/uQTh8Cr89LIRzDcWEGR53YKfMQX/VnTgUP4oby1iZGbgZ2nCC4IOz86aMM 0WrPu3VYTa7M0M3v7q1t/B+qzhctrIVR4VNbV3YSqF2gr91/hNhgY6w34tiy+hUidkmu qVX1WWRJUO3sIqwpa9HoYcK2Ztl7LwkyDroVLS2E6CNLwrPK5LaakoseX1RvILTkBIjl LNOweKWfk9+4r4624dPGk3Sy4VWA0f/ssrxqexenYxSekdFkN0zlUo71/LsQXmox7NkL Cnleb6FatGFYc2P+JATUjAcNIvLV2eQo5vwxjrNl4j9ixky/lE0B72faQfbje5hy2u3R SzwA== 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=4YG03gU0ZRJ6QL99ZRJIvBzFkeqE35J4RARqeAWO3xY=; b=hCEjKDq6KrG61rdKxBUO0kQa1Yd5aetBsRZvD68GDYCiv7VC2nRbPLRh/LBtrTYWpC DQiXNa1dmpVOPXW8KANoJBTd4cWzAsDn8l6k0yIFRJEvVrSHUEw62SBIF7er57eDwppU bSCi32Ms4Q9gN9Nuteq4C8bzigDUYPhoOgSqFUa9HFFusuAVjzG2HwQtK5EvCYDh8P53 7viwXvNHc0wy+TFg10P4KWLEyX0L+53F5Gzy1qXA+yDyu+4MCA04qxtxsLBSBMZ/91K1 /uS3pBrY8Sy2P67w3628Y549svBTPXGnArQdhFpyQqceruTakZLum5BQ2BCSJ8uwjeb0 ENKA== X-Gm-Message-State: ALoCoQn/QPHpLCKlcu8kgTXt0RfqpO3+Q9bM/fgIXutD/HgHxokYBACKB9ipws941wo+4lzCaV7JqlX6oXnaCMjsIv8LFZgZUg== X-Received: by 10.13.193.4 with SMTP id c4mr11958925ywd.192.1450264716089; Wed, 16 Dec 2015 03:18:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Wed, 16 Dec 2015 03:17:56 -0800 (PST) In-Reply-To: <87twnibx5p.fsf@latte.josefsson.org> References: <87twnibx5p.fsf@latte.josefsson.org> From: Eric Rescorla Date: Wed, 16 Dec 2015 03:17:56 -0800 Message-ID: To: Simon Josefsson Content-Type: multipart/alternative; boundary=001a114caa9e3bcecf05270211dd Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 11:18:39 -0000 --001a114caa9e3bcecf05270211dd Content-Type: text/plain; charset=UTF-8 On Wed, Dec 16, 2015 at 12:44 AM, Simon Josefsson wrote: > Eric Rescorla writes: > > > Watson kindly prepared some text that described the limits on what's safe > > for AES-GCM and restricting all algorithms with TLS 1.3 to that lower > > limit (2^{36} bytes), even though ChaCha doesn't have the same > > restriction. > > Can we see a brief writeup explaining the 2^36 number? > I believe Watson provided one a while back at: https://www.ietf.org/mail-archive/web/tls/current/msg18240.html > I don't like re-keying. It is usually a sign that your primitives are > too weak and you are attempting to hide that fact. To me, it is similar > to discard the first X byte of RC4 output. > To be clear: I would prefer not to rekey either, but the consensus at IETF Yokohama was that we were close enough to the limit that we probably had to. Would be happy to learn that we didn't. -Ekr If AES-GCM cannot provide confidentiality beyond 64GB (which would > surprise me somewhat), I believe we ought to be careful about > recommending it. > > Of course, the devil is in the details: if the risk is that the secret > key is leaked, that's fatal; if the risk is that the attacker can tell > whether two particular plaintext 128 byte blocks are the same or not in > the entire file, that can be a risk we can live with (similar to the > discard X bytes of RC4 fix). > > I believe 64GB is within the range that people download in a web browser > these days. More data intensive longer-running protocols often transfer > significantly more. > > /Simon > --001a114caa9e3bcecf05270211dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 16, 2015 at 12:44 AM, Simon Josefsson <= ;simon@josefsson.o= rg> wrote:
Eric Rescorla= <ekr@rtfm.com> writes:

> Watson kindly prepared some text that described the limits on what'= ;s safe
> for AES-GCM and restricting all algorithms with TLS 1.3 to that lower<= br> > limit (2^{36} bytes), even though ChaCha doesn't have the same
> restriction.

Can we see a brief writeup explaining the 2^36 number?

I believe Watson provided one a while back at:
=
=C2=A0
I don't like re-keying.=C2=A0 It is usually a sign that your primitives= are
too weak and you are attempting to hide that fact.=C2=A0 To me, it is simil= ar
to discard the first X byte of RC4 output.

<= div>To be clear: I would prefer not to rekey either, but the consensus at I= ETF Yokohama
was that we were close enough to the limit that we p= robably had to. Would be
happy to learn that we didn't.
=

-Ekr



=
If AES-GCM cannot provide confidentiality beyond 64GB (which would
surprise me somewhat), I believe we ought to be careful about
recommending it.

Of course, the devil is in the details: if the risk is that the secret
key is leaked, that's fatal; if the risk is that the attacker can tell<= br> whether two particular plaintext 128 byte blocks are the same or not in
the entire file, that can be a risk we can live with (similar to the
discard X bytes of RC4 fix).

I believe 64GB is within the range that people download in a web browser these days.=C2=A0 More data intensive longer-running protocols often transf= er
significantly more.

/Simon

--001a114caa9e3bcecf05270211dd-- From nobody Wed Dec 16 04:07:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0461B2AB5 for ; Wed, 16 Dec 2015 04:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 W8Yqw5ytkn0K for ; Wed, 16 Dec 2015 04:07:49 -0800 (PST) Received: from vsp5.ballou.se (vsp5.ballou.se [91.189.40.84]) by ietfa.amsl.com (Postfix) with SMTP id D09DF1B2AA9 for ; Wed, 16 Dec 2015 04:07:48 -0800 (PST) X-Halon-ID: 9d6f0840-a3ed-11e5-aba1-005056921986 X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04 Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp5.ballou.se (Halon Mail Gateway) with ESMTP for ; Wed, 16 Dec 2015 13:07:44 +0100 (CET) Received: from [192.168.0.190] (c-1ec0e555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.192.30]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 33686C9378 for ; Wed, 16 Dec 2015 13:07:44 +0100 (CET) References: <87twnibx5p.fsf@latte.josefsson.org> To: tls@ietf.org From: =?UTF-8?Q?Henrick_Hellstr=c3=b6m?= Message-ID: <56715402.9070303@streamsec.se> Date: Wed, 16 Dec 2015 13:07:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Data volume limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list 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, 16 Dec 2015 12:07:51 -0000 On 2015-12-16 12:17, Eric Rescorla wrote: > Can we see a brief writeup explaining the 2^36 number? > > > I believe Watson provided one a while back at: > https://www.ietf.org/mail-archive/web/tls/current/msg18240.html One rather obvious problem with trying to equate probability of loss of confidentiality with the advantage for an IND-KPA adversary, is that the IND-models don't account for the length of the plain text. The real life problem is that you lose a lot more information a lot faster, by revealing the amount and frequency of the data transfer, than through the KPA distinguisher for CTR mode. And, furthermore, the IND-KPA distinguisher is a fairly well understood abstract artifact of CTR mode. It is not obviously relevant to compare it to distinguishers for primitives such as RC4, which typically indicate that there might be even worse problems. From nobody Wed Dec 16 04:11:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929F81A6FDF for ; Wed, 16 Dec 2015 04:11:14 -0800 (PST) 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 ZXxUslqfF1BR for ; Wed, 16 Dec 2015 04:11:11 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FCF31A6FC6 for ; Wed, 16 Dec 2015 04:11:11 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id p187so59673580qkd.1 for ; Wed, 16 Dec 2015 04:11:11 -0800 (PST) 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=BNkwNBIUckXvyaAAMnP56PtjxVG9VBEWmM3UFyofpMI=; b=eqZjtzS6+ufbty1pRBs1SlH3oY5+ZvkRdbATqY83+sVbpcSmQLmX3gC7rrkuU31sWp FPGfiRngBYkgVY2cWpk4dr/zJDgfceda2de1twDbW1bXPPvw9DRkG+gPHnqiyg4aphzl 02laOZ6ukvTzNRTaA2O0pDCKsV8w/4Ho9POhKUTWfAx8TKB/jYGkSNdVVSazlgVFFqo9 Eek6+agleXPGgfZRuw9HUrvTn0gfoP72Wlu0tG4gz2yRsYgld9I1jereporeEQLRV7qI SVQCE8vneifOdlz+BXaUm/OB6GzqJZ4tXPduuTKBvviZc8F1EmWKUJQ19I9wSNf1V/2h kCIw== MIME-Version: 1.0 X-Received: by 10.129.72.84 with SMTP id v81mr8325617ywa.101.1450267870242; Wed, 16 Dec 2015 04:11:10 -0800 (PST) Received: by 10.129.148.131 with HTTP; Wed, 16 Dec 2015 04:11:10 -0800 (PST) In-Reply-To: References: <87twnibx5p.fsf@latte.josefsson.org> Date: Wed, 16 Dec 2015 07:11:10 -0500 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 12:11:14 -0000 On Wed, Dec 16, 2015 at 6:17 AM, Eric Rescorla wrote: > > > On Wed, Dec 16, 2015 at 12:44 AM, Simon Josefsson > wrote: >> >> Eric Rescorla writes: >> >> > Watson kindly prepared some text that described the limits on what's >> > safe >> > for AES-GCM and restricting all algorithms with TLS 1.3 to that lower >> > limit (2^{36} bytes), even though ChaCha doesn't have the same >> > restriction. >> >> Can we see a brief writeup explaining the 2^36 number? > > > I believe Watson provided one a while back at: > https://www.ietf.org/mail-archive/web/tls/current/msg18240.html > >> >> I don't like re-keying. It is usually a sign that your primitives are >> too weak and you are attempting to hide that fact. To me, it is similar >> to discard the first X byte of RC4 output. > > > To be clear: I would prefer not to rekey either, but the consensus at IETF > Yokohama > was that we were close enough to the limit that we probably had to. Would be > happy to learn that we didn't. If you come up with a number for how many bytes we would send maximally, I can see what the probability of a distinguisher would be. There are a bunch of places I was sloppy. Personally I think 2^36 bytes over one connection is quite a lot, but it appears that people are still worried about about this edge case. Rekeying isn't that complicated conceptually, or from the standpoint of how to integrate it in. Reauthentication is a lot worse. > > -Ekr > > > >> If AES-GCM cannot provide confidentiality beyond 64GB (which would >> surprise me somewhat), I believe we ought to be careful about >> recommending it. >> >> Of course, the devil is in the details: if the risk is that the secret >> key is leaked, that's fatal; if the risk is that the attacker can tell >> whether two particular plaintext 128 byte blocks are the same or not in >> the entire file, that can be a risk we can live with (similar to the >> discard X bytes of RC4 fix). >> >> I believe 64GB is within the range that people download in a web browser >> these days. More data intensive longer-running protocols often transfer >> significantly more. >> >> /Simon > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Dec 16 04:13:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC46C1B2B0A for ; Wed, 16 Dec 2015 04:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, 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 Z1lTlehF5fKb for ; Wed, 16 Dec 2015 04:13:22 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E841B2B0B for ; Wed, 16 Dec 2015 04:13:22 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id p187so59752123qkd.1 for ; Wed, 16 Dec 2015 04:13:22 -0800 (PST) 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=woJHjoHV0sgIUHH3ykuQbNoigAaa82WJ7Ns3N92aNLM=; b=Yd109YHMoVPSJIl0uHLFB64Bbmr1HL0uvCW7M+DIDmbAGuciz6VsKH8v7vBE+I3wmy YlTHesAuVgvbpfqFx6GVjc16OWxMGoPbO1w+nGKinxybcSfDMc+skThVUWVNmMFtmSeh dcvZI4zxcYAjH7DFQ8Ip2IOf9b6uGDeQL8ZBerwPuHoZMrE5EIFLgZAmZYEy4w4TpJxS LtS8EbdNx/bI0+XOGi6jXIUOCU+0Sv+lXFWy+Wb2vFfhPj3v4GgtYEddCcwKDirPVXiB iQ2bnBMJ9ncFxPv0+5/ct4VQvOGdEUcX9Ajuft3fq/jC14xIFfj+AmhuCRgT+uvfXzGL WEIA== MIME-Version: 1.0 X-Received: by 10.129.72.84 with SMTP id v81mr8334387ywa.101.1450268001872; Wed, 16 Dec 2015 04:13:21 -0800 (PST) Received: by 10.129.148.131 with HTTP; Wed, 16 Dec 2015 04:13:21 -0800 (PST) In-Reply-To: <56715402.9070303@streamsec.se> References: <87twnibx5p.fsf@latte.josefsson.org> <56715402.9070303@streamsec.se> Date: Wed, 16 Dec 2015 07:13:21 -0500 Message-ID: From: Watson Ladd To: =?UTF-8?Q?Henrick_Hellstr=C3=B6m?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 12:13:24 -0000 On Wed, Dec 16, 2015 at 7:07 AM, Henrick Hellstr=C3=B6m wrote: > On 2015-12-16 12:17, Eric Rescorla wrote: >> >> Can we see a brief writeup explaining the 2^36 number? >> >> >> I believe Watson provided one a while back at: >> https://www.ietf.org/mail-archive/web/tls/current/msg18240.html > > > One rather obvious problem with trying to equate probability of loss of > confidentiality with the advantage for an IND-KPA adversary, is that the > IND-models don't account for the length of the plain text. > > The real life problem is that you lose a lot more information a lot faste= r, > by revealing the amount and frequency of the data transfer, than through = the > KPA distinguisher for CTR mode. > > And, furthermore, the IND-KPA distinguisher is a fairly well understood > abstract artifact of CTR mode. It is not obviously relevant to compare it= to > distinguishers for primitives such as RC4, which typically indicate that > there might be even worse problems. Sure it is. An attacker can distinguish RC4 from random with a very high probability (I didn't work it out, but it's an exercise in Bayes theorem and your favorite biases). I agree this doesn't cover side channel information related to plaintext length and timing, but there is a padding facility intended to help with that. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Dec 16 04:21:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893C81B2B42 for ; Wed, 16 Dec 2015 04:21:57 -0800 (PST) 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 MBLySLhxi14I for ; Wed, 16 Dec 2015 04:21:55 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30B51B2B2B for ; Wed, 16 Dec 2015 04:21:54 -0800 (PST) Received: from BY2PR09MB126.namprd09.prod.outlook.com (10.242.37.156) by BY2PR09MB128.namprd09.prod.outlook.com (10.242.37.28) with Microsoft SMTP Server (TLS) id 15.1.355.16; Wed, 16 Dec 2015 12:21:52 +0000 Received: from BY2PR09MB126.namprd09.prod.outlook.com ([10.242.37.156]) by BY2PR09MB126.namprd09.prod.outlook.com ([10.242.37.156]) with mapi id 15.01.0355.012; Wed, 16 Dec 2015 12:21:52 +0000 From: "Dang, Quynh" To: Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] Data volume limits Thread-Index: AQHRN326ECu0fHUB6EGja4Q2uc5EIJ7NTTAHgAAqpwCAAAZ5sg== Date: Wed, 16 Dec 2015 12:21:51 +0000 Message-ID: References: <87twnibx5p.fsf@latte.josefsson.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-originating-ip: [129.6.222.126] x-microsoft-exchange-diagnostics: 1; BY2PR09MB128; 5:9VH64DXbensnvR6Bd3M5gMjW78dgHDYc5nJgeVGDWnEEZChUGCb6OeNxnUwiGeN/vsSFlmRiavRFoYnU7fIUY7MRMh+3bL183QTirPT/2f/pgcm9/y6DHu+BaZougIMYEaYvc4URcqOIy7ZMpqrrGg==; 24:i6AcHseT8yX6IQHE0iLqExhqlWJKDaJqG7NszlSAzGyQms2CwFQewx7T+opN8ynvg451uqPyzQutfhSmyf57uGkE+LzTpkeaer7zq7yHmAE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR09MB128; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR09MB128; BCL:0; PCL:0; RULEID:; SRVR:BY2PR09MB128; x-forefront-prvs: 0792DBEAD0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(377454003)(24454002)(199003)(19580405001)(105586002)(19580395003)(77096005)(40100003)(76576001)(2501003)(106356001)(19617315012)(16236675004)(19627405001)(81156007)(99286002)(86362001)(66066001)(87936001)(107886002)(189998001)(5001770100001)(97736004)(1220700001)(5001960100002)(10400500002)(15975445007)(5003600100002)(101416001)(2900100001)(1096002)(76176999)(5002640100001)(11100500001)(2950100001)(102836003)(3846002)(54356999)(5004730100002)(586003)(6116002)(5008740100001)(50986999)(122556002)(33656002)(19625215002)(74316001)(92566002)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR09MB128; H:BY2PR09MB126.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR09MB126923BEB23720E72077364F3EF0BY2PR09MB126namprd_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2015 12:21:51.3933 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR09MB128 Archived-At: Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 12:21:57 -0000 --_000_BY2PR09MB126923BEB23720E72077364F3EF0BY2PR09MB126namprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eric, I explained the issue before and some other people recently explained it ag= ain on this thread. AES has 128-bit block. Therefore, when there are 2^64 = or more ciphertext blocks, there are likely collisions among the ciphertext= blocks (the collision probability increases rapidly when the number of cip= hertext blocks increases above 2^64 ( 2^n/2 in generic term) ). However, the only information the attacker can gain from ANY pair of collid= ed ciphertext blocks is that their corresponding plaintext blocks are proba= bly different ones because the chance for them to be the same is 1/2^128 (1= /2^n in generic term) and this is NOT better than a random guess. So, you d= on't lose anything actually. As a pseudorandom function, AES completely fails under any mode when the nu= mber of ciphertext blocks gets above 2^64. When the counter is effectively= only 64 bits (instead of 96 bits as in TLS 1.3), the data complexity shoul= d be below 2^32 blocks because the same input block and the same key can be= repeated 2^32 times to find a collision in the ciphertext blocks. If you = want a negligible collision probability, the number of data blocks should b= e way below 2^32 in this situation. However, the confidentiality of the plaintext blocks is not lost at all as = long as the counter number does not repeat. Quynh. ________________________________ From: TLS on behalf of Eric Rescorla Sent: Wednesday, December 16, 2015 6:17 AM To: Simon Josefsson Cc: tls@ietf.org Subject: Re: [TLS] Data volume limits On Wed, Dec 16, 2015 at 12:44 AM, Simon Josefsson > wrote: Eric Rescorla > writes: > Watson kindly prepared some text that described the limits on what's safe > for AES-GCM and restricting all algorithms with TLS 1.3 to that lower > limit (2^{36} bytes), even though ChaCha doesn't have the same > restriction. Can we see a brief writeup explaining the 2^36 number? I believe Watson provided one a while back at: https://www.ietf.org/mail-archive/web/tls/current/msg18240.html I don't like re-keying. It is usually a sign that your primitives are too weak and you are attempting to hide that fact. To me, it is similar to discard the first X byte of RC4 output. To be clear: I would prefer not to rekey either, but the consensus at IETF = Yokohama was that we were close enough to the limit that we probably had to. Would b= e happy to learn that we didn't. -Ekr If AES-GCM cannot provide confidentiality beyond 64GB (which would surprise me somewhat), I believe we ought to be careful about recommending it. Of course, the devil is in the details: if the risk is that the secret key is leaked, that's fatal; if the risk is that the attacker can tell whether two particular plaintext 128 byte blocks are the same or not in the entire file, that can be a risk we can live with (similar to the discard X bytes of RC4 fix). I believe 64GB is within the range that people download in a web browser these days. More data intensive longer-running protocols often transfer significantly more. /Simon --_000_BY2PR09MB126923BEB23720E72077364F3EF0BY2PR09MB126namprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Eric,


I explained the issue before and some other people recently explained it= again on this thread. AES has 128-bit block. Therefore, when there are 2^6= 4  or more ciphertext blocks, there are likely collisions among t= he ciphertext blocks (the collision probability increases rapidly when the number of ciphertext blocks increases above 2^6= 4 ( 2^n/2 in generic term) ). 


However, the only information the attacker can gain from ANY pair of&nbs= p;collided ciphertext blocks is that their corresponding plaintext blocks&n= bsp;are probably different ones because the chance for them to be the same = is 1/2^128 (1/2^n in generic term) and this is NOT better than a random guess. So, you don't lose anything actual= ly. 


As a pseudorandom function, AES completely fails under any mode whe= n the number of ciphertext blocks gets above 2^64.  When the counter i= s effectively only 64 bits (instead of 96 bits as in TLS 1.3), the dat= a complexity should be below 2^32 blocks because the same input block and the same key can be repeated 2^32 times to find a=  collision in the ciphertext blocks.  If you want a negligible co= llision probability, the number of data blocks should be way below 2^32 in = this situation. 


However, the confidentiality of the pla= intext blocks is not lost at all as long as the counter number does no= t repeat. 


Quynh. 





From: TLS <tls-bounces@i= etf.org> on behalf of Eric Rescorla <ekr@rtfm.com>
Sent: Wednesday, December 16, 2015 6:17 AM
To: Simon Josefsson
Cc: tls@ietf.org
Subject: Re: [TLS] Data volume limits
 


On Wed, Dec 16, 2015 at 12:44 AM, Simon Josefsso= n <simon@josefsso= n.org> wrote:
Eric Rescorla <ekr@rtfm= .com> writes:

> Watson kindly prepared some text that described the limits on what's s= afe
> for AES-GCM and restricting all algorithms with TLS 1.3 to that lower<= br> > limit (2^{36} bytes), even though ChaCha doesn't have the same
> restriction.

Can we see a brief writeup explaining the 2^36 number?

I believe Watson provided one a while back at:
 
I don't like re-keying.  It is usually a sign that your primitives are=
too weak and you are attempting to hide that fact.  To me, it is simil= ar
to discard the first X byte of RC4 output.

To be clear: I would prefer not to rekey either, but the consensus at = IETF Yokohama
was that we were close enough to the limit that we probably had to. Wo= uld be
happy to learn that we didn't.

-Ekr



If AES-GCM cannot provide confidentiality beyond 64GB (which would
surprise me somewhat), I believe we ought to be careful about
recommending it.

Of course, the devil is in the details: if the risk is that the secret
key is leaked, that's fatal; if the risk is that the attacker can tell
whether two particular plaintext 128 byte blocks are the same or not in
the entire file, that can be a risk we can live with (similar to the
discard X bytes of RC4 fix).

I believe 64GB is within the range that people download in a web browser these days.  More data intensive longer-running protocols often transf= er
significantly more.

/Simon

--_000_BY2PR09MB126923BEB23720E72077364F3EF0BY2PR09MB126namprd_-- From nobody Wed Dec 16 07:44:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DD51A038A for ; Wed, 16 Dec 2015 07:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 mwnINV1EWCmU for ; Wed, 16 Dec 2015 07:44:23 -0800 (PST) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 05F7D1A0387 for ; Wed, 16 Dec 2015 07:44:22 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id tBGFiLGc023753 for ; Wed, 16 Dec 2015 10:44:21 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: "tls@ietf.org" Thread-Topic: [TLS] Data volume limits Thread-Index: AQHRN33Tde9nh48KlkmRxpLGJ4HFm57NTcOpgAB95gCAABHcgP//xuuA Date: Wed, 16 Dec 2015 15:44:20 +0000 Message-ID: References: <87twnibx5p.fsf@latte.josefsson.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-originating-ip: [172.25.177.65] Content-Type: multipart/alternative; boundary="_000_D296D6CB213C9urillmitedu_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2015-12-16_07:2015-12-16,2015-12-16,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-1511060000 definitions=main-1512160262 Archived-At: Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 15:44:26 -0000 --_000_D296D6CB213C9urillmitedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T0ssIGxldCBtZSB0cnkgYW4gZXh0cmVtZWx5IG5hw692ZSBhcHByb2FjaC4NCg0KU2F5LCBhbiBh ZHZlcnNhcnkgb2JzZXJ2ZXMgYSB0b24gb2YgVExTIHRyYWZmaWMgYmV0d2VlbiBBIGFuZCBCLiBV c2luZyBhcHByb2FjaCB0aGF0IFdhdHNvbiBhbmQgb3RoZXJzIG91dGxpbmVkLCBoZSBjYW4gbm93 IHRlbGwgdGhhdCB0aGlzIGlzIG5vdCBhIHRydWx5IHJhbmRvbSBzdHJlYW0gYnV0IGEgYnVuY2gg b2YgZW5jcnlwdGVkIGRhdGEuIE15IHF1ZXN0aW9uIGlzLCBmcm9tIHByYWN0aWNhbCByZWFsLXdv cmxkIHBvaW50IG9mIHZpZXcgLSBzbyB3aGF0PyAoT2YgY291cnNlLCBiZXlvbmQgdGhlIGFiaWxp dHkgdG8gcHVibGlzaCBhIHJlYWwgcGFwZXIgdGhhdCBJTkQtKiBoYXMgYmVlbiBjb21wcm9taXNl ZCA6KQ0KDQpJZiB0aGVyZSBhcmUgcHJhY3RpY2FsIGNvbnNlcXVlbmNlcywgbGlrZSBsb3NzIG9m IGNvbmZpZGVudGlhbGl0eSDigJMgSeKAmW0gZHlpbmcgdG8gaGVhciB0aGUgb3V0bGluZSBvZiBh IHByYWN0aWNhbCBhdHRhY2suDQotLQ0KUmVnYXJkcywNClVyaSBCbHVtZW50aGFsDQoNCkZyb206 IFRMUyA8dGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnPj4g b24gYmVoYWxmIG9mICJEYW5nLCBRdXluaCIgPHF1eW5oLmRhbmdAbmlzdC5nb3Y8bWFpbHRvOnF1 eW5oLmRhbmdAbmlzdC5nb3Y+Pg0KRGF0ZTogV2VkbmVzZGF5LCBEZWNlbWJlciAxNiwgMjAxNSBh dCAwNzoyMQ0KVG86IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0u Y29tPj4sICJ0bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4iIDx0bHNAaWV0Zi5vcmc8 bWFpbHRvOnRsc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW1RMU10gRGF0YSB2b2x1bWUgbGlt aXRzDQoNCg0KSGkgRXJpYywNCg0KDQpJIGV4cGxhaW5lZCB0aGUgaXNzdWUgYmVmb3JlIGFuZCBz b21lIG90aGVyIHBlb3BsZSByZWNlbnRseSBleHBsYWluZWQgaXQgYWdhaW4gb24gdGhpcyB0aHJl YWQuIEFFUyBoYXMgMTI4LWJpdCBibG9jay4gVGhlcmVmb3JlLCB3aGVuIHRoZXJlIGFyZSAyXjY0 ICBvciBtb3JlIGNpcGhlcnRleHQgYmxvY2tzLCB0aGVyZSBhcmUgbGlrZWx5IGNvbGxpc2lvbnMg YW1vbmcgdGhlIGNpcGhlcnRleHQgYmxvY2tzICh0aGUgY29sbGlzaW9uIHByb2JhYmlsaXR5IGlu Y3JlYXNlcyByYXBpZGx5IHdoZW4gdGhlIG51bWJlciBvZiBjaXBoZXJ0ZXh0IGJsb2NrcyBpbmNy ZWFzZXMgYWJvdmUgMl42NCAoIDJebi8yIGluIGdlbmVyaWMgdGVybSkgKS4NCg0KDQpIb3dldmVy LCB0aGUgb25seSBpbmZvcm1hdGlvbiB0aGUgYXR0YWNrZXIgY2FuIGdhaW4gZnJvbSBBTlkgcGFp ciBvZiBjb2xsaWRlZCBjaXBoZXJ0ZXh0IGJsb2NrcyBpcyB0aGF0IHRoZWlyIGNvcnJlc3BvbmRp bmcgcGxhaW50ZXh0IGJsb2NrcyBhcmUgcHJvYmFibHkgZGlmZmVyZW50IG9uZXMgYmVjYXVzZSB0 aGUgY2hhbmNlIGZvciB0aGVtIHRvIGJlIHRoZSBzYW1lIGlzIDEvMl4xMjggKDEvMl5uIGluIGdl bmVyaWMgdGVybSkgYW5kIHRoaXMgaXMgTk9UIGJldHRlciB0aGFuIGEgcmFuZG9tIGd1ZXNzLiBT bywgeW91IGRvbid0IGxvc2UgYW55dGhpbmcgYWN0dWFsbHkuDQoNCg0KQXMgYSBwc2V1ZG9yYW5k b20gZnVuY3Rpb24sIEFFUyBjb21wbGV0ZWx5IGZhaWxzIHVuZGVyIGFueSBtb2RlIHdoZW4gdGhl IG51bWJlciBvZiBjaXBoZXJ0ZXh0IGJsb2NrcyBnZXRzIGFib3ZlIDJeNjQuICBXaGVuIHRoZSBj b3VudGVyIGlzIGVmZmVjdGl2ZWx5IG9ubHkgNjQgYml0cyAoaW5zdGVhZCBvZiA5NiBiaXRzIGFz IGluIFRMUyAxLjMpLCB0aGUgZGF0YSBjb21wbGV4aXR5IHNob3VsZCBiZSBiZWxvdyAyXjMyIGJs b2NrcyBiZWNhdXNlIHRoZSBzYW1lIGlucHV0IGJsb2NrIGFuZCB0aGUgc2FtZSBrZXkgY2FuIGJl IHJlcGVhdGVkIDJeMzIgdGltZXMgdG8gZmluZCBhIGNvbGxpc2lvbiBpbiB0aGUgY2lwaGVydGV4 dCBibG9ja3MuICBJZiB5b3Ugd2FudCBhIG5lZ2xpZ2libGUgY29sbGlzaW9uIHByb2JhYmlsaXR5 LCB0aGUgbnVtYmVyIG9mIGRhdGEgYmxvY2tzIHNob3VsZCBiZSB3YXkgYmVsb3cgMl4zMiBpbiB0 aGlzIHNpdHVhdGlvbi4NCg0KDQpIb3dldmVyLCB0aGUgY29uZmlkZW50aWFsaXR5IG9mIHRoZSBw bGFpbnRleHQgYmxvY2tzIGlzIG5vdCBsb3N0IGF0IGFsbCBhcyBsb25nIGFzIHRoZSBjb3VudGVy IG51bWJlciBkb2VzIG5vdCByZXBlYXQuDQoNCg0KUXV5bmguDQoNCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBUTFMgPHRscy1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBFcmljIFJlc2NvcmxhIDxl a3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+DQpTZW50OiBXZWRuZXNkYXksIERlY2Vt YmVyIDE2LCAyMDE1IDY6MTcgQU0NClRvOiBTaW1vbiBKb3NlZnNzb24NCkNjOiB0bHNAaWV0Zi5v cmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVExTXSBEYXRhIHZvbHVtZSBs aW1pdHMNCg0KDQoNCk9uIFdlZCwgRGVjIDE2LCAyMDE1IGF0IDEyOjQ0IEFNLCBTaW1vbiBKb3Nl ZnNzb24gPHNpbW9uQGpvc2Vmc3Nvbi5vcmc8bWFpbHRvOnNpbW9uQGpvc2Vmc3Nvbi5vcmc+PiB3 cm90ZToNCkVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4g d3JpdGVzOg0KDQo+IFdhdHNvbiBraW5kbHkgcHJlcGFyZWQgc29tZSB0ZXh0IHRoYXQgZGVzY3Jp YmVkIHRoZSBsaW1pdHMgb24gd2hhdCdzIHNhZmUNCj4gZm9yIEFFUy1HQ00gYW5kIHJlc3RyaWN0 aW5nIGFsbCBhbGdvcml0aG1zIHdpdGggVExTIDEuMyB0byB0aGF0IGxvd2VyDQo+IGxpbWl0ICgy XnszNn0gYnl0ZXMpLCBldmVuIHRob3VnaCBDaGFDaGEgZG9lc24ndCBoYXZlIHRoZSBzYW1lDQo+ IHJlc3RyaWN0aW9uLg0KDQpDYW4gd2Ugc2VlIGEgYnJpZWYgd3JpdGV1cCBleHBsYWluaW5nIHRo ZSAyXjM2IG51bWJlcj8NCg0KSSBiZWxpZXZlIFdhdHNvbiBwcm92aWRlZCBvbmUgYSB3aGlsZSBi YWNrIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90bHMvY3VycmVu dC9tc2cxODI0MC5odG1sDQoNCkkgZG9uJ3QgbGlrZSByZS1rZXlpbmcuICBJdCBpcyB1c3VhbGx5 IGEgc2lnbiB0aGF0IHlvdXIgcHJpbWl0aXZlcyBhcmUNCnRvbyB3ZWFrIGFuZCB5b3UgYXJlIGF0 dGVtcHRpbmcgdG8gaGlkZSB0aGF0IGZhY3QuICBUbyBtZSwgaXQgaXMgc2ltaWxhcg0KdG8gZGlz Y2FyZCB0aGUgZmlyc3QgWCBieXRlIG9mIFJDNCBvdXRwdXQuDQoNClRvIGJlIGNsZWFyOiBJIHdv dWxkIHByZWZlciBub3QgdG8gcmVrZXkgZWl0aGVyLCBidXQgdGhlIGNvbnNlbnN1cyBhdCBJRVRG IFlva29oYW1hDQp3YXMgdGhhdCB3ZSB3ZXJlIGNsb3NlIGVub3VnaCB0byB0aGUgbGltaXQgdGhh dCB3ZSBwcm9iYWJseSBoYWQgdG8uIFdvdWxkIGJlDQpoYXBweSB0byBsZWFybiB0aGF0IHdlIGRp ZG4ndC4NCg0KLUVrcg0KDQoNCg0KSWYgQUVTLUdDTSBjYW5ub3QgcHJvdmlkZSBjb25maWRlbnRp YWxpdHkgYmV5b25kIDY0R0IgKHdoaWNoIHdvdWxkDQpzdXJwcmlzZSBtZSBzb21ld2hhdCksIEkg YmVsaWV2ZSB3ZSBvdWdodCB0byBiZSBjYXJlZnVsIGFib3V0DQpyZWNvbW1lbmRpbmcgaXQuDQoN Ck9mIGNvdXJzZSwgdGhlIGRldmlsIGlzIGluIHRoZSBkZXRhaWxzOiBpZiB0aGUgcmlzayBpcyB0 aGF0IHRoZSBzZWNyZXQNCmtleSBpcyBsZWFrZWQsIHRoYXQncyBmYXRhbDsgaWYgdGhlIHJpc2sg aXMgdGhhdCB0aGUgYXR0YWNrZXIgY2FuIHRlbGwNCndoZXRoZXIgdHdvIHBhcnRpY3VsYXIgcGxh aW50ZXh0IDEyOCBieXRlIGJsb2NrcyBhcmUgdGhlIHNhbWUgb3Igbm90IGluDQp0aGUgZW50aXJl IGZpbGUsIHRoYXQgY2FuIGJlIGEgcmlzayB3ZSBjYW4gbGl2ZSB3aXRoIChzaW1pbGFyIHRvIHRo ZQ0KZGlzY2FyZCBYIGJ5dGVzIG9mIFJDNCBmaXgpLg0KDQpJIGJlbGlldmUgNjRHQiBpcyB3aXRo aW4gdGhlIHJhbmdlIHRoYXQgcGVvcGxlIGRvd25sb2FkIGluIGEgd2ViIGJyb3dzZXINCnRoZXNl IGRheXMuICBNb3JlIGRhdGEgaW50ZW5zaXZlIGxvbmdlci1ydW5uaW5nIHByb3RvY29scyBvZnRl biB0cmFuc2Zlcg0Kc2lnbmlmaWNhbnRseSBtb3JlLg0KDQovU2ltb24NCg0K --_000_D296D6CB213C9urillmitedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+T0ss IGxldCBtZSB0cnkgYW4gZXh0cmVtZWx5IG5hw692ZSBhcHByb2FjaC48L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PlNheSwgYW4gYWR2ZXJzYXJ5IG9ic2VydmVzIGEgdG9uIG9mIFRMUyB0 cmFmZmljIGJldHdlZW4gQSBhbmQgQi4gVXNpbmcgYXBwcm9hY2ggdGhhdCBXYXRzb24gYW5kIG90 aGVycyBvdXRsaW5lZCwgaGUgY2FuIG5vdyB0ZWxsIHRoYXQgdGhpcyBpcyBub3QgYSB0cnVseSBy YW5kb20gc3RyZWFtIGJ1dCBhIGJ1bmNoIG9mIGVuY3J5cHRlZCBkYXRhLiBNeSBxdWVzdGlvbiBp cywgZnJvbSBwcmFjdGljYWwgcmVhbC13b3JsZCBwb2ludCBvZiB2aWV3DQogLSBzbyB3aGF0PyAo T2YgY291cnNlLCBiZXlvbmQgdGhlIGFiaWxpdHkgdG8gcHVibGlzaCBhIHJlYWwgcGFwZXIgdGhh dCBJTkQtKiBoYXMgYmVlbiBjb21wcm9taXNlZCA6KTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+SWYgdGhlcmUgYXJlIHByYWN0aWNhbCBjb25zZXF1ZW5jZXMsIGxpa2UgbG9zcyBvZiBj b25maWRlbnRpYWxpdHkg4oCTIEnigJltIGR5aW5nIHRvIGhlYXIgdGhlIG91dGxpbmUgb2YgYSBw cmFjdGljYWwgYXR0YWNrLjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGZvbnQgY2xhc3M9IkFwcGxlLXN0 eWxlLXNwYW4iIGNvbG9yPSIjMDAwMDAwIj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIg ZmFjZT0iQ2FsaWJyaSI+LS08L2ZvbnQ+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBjbGFzcz0i QXBwbGUtc3R5bGUtc3BhbiIgY29sb3I9IiMwMDAwMDAiPjxmb250IGNsYXNzPSJBcHBsZS1zdHls ZS1zcGFuIiBmYWNlPSJDYWxpYnJpIj5SZWdhcmRzLDwvZm9udD48L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBjb2xvcj0iIzAwMDAwMCI+PGZvbnQgY2xh c3M9IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9IkNhbGlicmkiPlVyaSBCbHVtZW50aGFsPC9mb250 PjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4g aWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVIt Qk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJP VFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVIt VE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElO Ry1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFu PlRMUyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnIj50bHMtYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtEYW5nLCBRdXluaCZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnF1eW5oLmRhbmdAbmlzdC5nb3YiPnF1eW5oLmRhbmdAbmlzdC5n b3Y8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3Nw YW4+V2VkbmVzZGF5LCBEZWNlbWJlciAxNiwgMjAxNSBhdCAwNzoyMTxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9 Im1haWx0bzpla3JAcnRmbS5jb20iPmVrckBydGZtLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVm PSJtYWlsdG86dGxzQGlldGYub3JnIj50bHNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86dGxzQGlldGYub3JnIj50bHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtUTFNdIERhdGEgdm9s dW1lIGxpbWl0czxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlk PSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6 ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRp dj48c3R5bGUgdHlwZT0idGV4dC9jc3MiIHN0eWxlPSJkaXNwbGF5Om5vbmU7Ij48IS0tIFAge21h cmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjA7fSAtLT48L3N0eWxlPg0KPGRpdiBkaXI9Imx0ciI+ DQo8ZGl2IGlkPSJkaXZ0YWdkZWZhdWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2Nv bG9yOiMwMDAwMDA7YmFja2dyb3VuZC1jb2xvcjojRkZGRkZGO2ZvbnQtZmFtaWx5OkNhbGlicmks QXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7Ij4NCjxwPkhpIEVyaWMsPC9wPg0KPHA+PGJyPg0K PC9wPg0KPHA+SSBleHBsYWluZWQgdGhlIGlzc3VlIGJlZm9yZSBhbmQgc29tZSBvdGhlciBwZW9w bGUgcmVjZW50bHkgZXhwbGFpbmVkIGl0IGFnYWluIG9uIHRoaXMgdGhyZWFkLiBBRVMgaGFzIDEy OC1iaXQgYmxvY2suIFRoZXJlZm9yZSwgd2hlbiB0aGVyZSBhcmUgMl42NCAmbmJzcDtvciBtb3Jl Jm5ic3A7Y2lwaGVydGV4dCBibG9ja3MsIHRoZXJlIGFyZSBsaWtlbHkgY29sbGlzaW9ucyBhbW9u ZyB0aGUgY2lwaGVydGV4dCBibG9ja3MgKHRoZSBjb2xsaXNpb24gcHJvYmFiaWxpdHkNCiBpbmNy ZWFzZXMgcmFwaWRseSB3aGVuIHRoZSBudW1iZXIgb2YgY2lwaGVydGV4dCBibG9ja3MgaW5jcmVh c2VzIGFib3ZlIDJeNjQgKCAyXm4vMiBpbiBnZW5lcmljIHRlcm0pJm5ic3A7KS4mbmJzcDs8L3A+ DQo8cD48YnI+DQo8L3A+DQo8cD5Ib3dldmVyLCB0aGUgb25seSBpbmZvcm1hdGlvbiB0aGUgYXR0 YWNrZXIgY2FuIGdhaW4gZnJvbSBBTlkgcGFpciBvZiZuYnNwO2NvbGxpZGVkIGNpcGhlcnRleHQg YmxvY2tzIGlzIHRoYXQgdGhlaXIgY29ycmVzcG9uZGluZyBwbGFpbnRleHQgYmxvY2tzJm5ic3A7 YXJlIHByb2JhYmx5IGRpZmZlcmVudCBvbmVzIGJlY2F1c2UgdGhlIGNoYW5jZSBmb3IgdGhlbSB0 byBiZSB0aGUgc2FtZSBpcyAxLzJeMTI4ICgxLzJebiBpbiBnZW5lcmljIHRlcm0pIGFuZCB0aGlz DQogaXMgTk9UIGJldHRlciB0aGFuIGEmbmJzcDtyYW5kb20gZ3Vlc3MuIFNvLCB5b3UgZG9uJ3Qg bG9zZSBhbnl0aGluZyBhY3R1YWxseS4mbmJzcDs8L3A+DQo8cD48YnI+DQo8L3A+DQo8cD5BcyBh IHBzZXVkb3JhbmRvbSZuYnNwO2Z1bmN0aW9uLCBBRVMgY29tcGxldGVseSBmYWlscyB1bmRlciBh bnkgbW9kZSB3aGVuIHRoZSBudW1iZXIgb2YgY2lwaGVydGV4dCBibG9ja3MgZ2V0cyBhYm92ZSAy XjY0LiAmbmJzcDtXaGVuIHRoZSBjb3VudGVyIGlzIGVmZmVjdGl2ZWx5Jm5ic3A7b25seSA2NCBi aXRzIChpbnN0ZWFkIG9mIDk2IGJpdHMgYXMgaW4gVExTIDEuMyksIHRoZSBkYXRhIGNvbXBsZXhp dHkgc2hvdWxkIGJlIGJlbG93IDJeMzIgYmxvY2tzIGJlY2F1c2UNCiB0aGUgc2FtZSBpbnB1dCBi bG9jayBhbmQgdGhlIHNhbWUga2V5IGNhbiBiZSByZXBlYXRlZCAyXjMyIHRpbWVzIHRvIGZpbmQg YSZuYnNwO2NvbGxpc2lvbiBpbiB0aGUgY2lwaGVydGV4dCBibG9ja3MuICZuYnNwO0lmIHlvdSB3 YW50IGEgbmVnbGlnaWJsZSBjb2xsaXNpb24gcHJvYmFiaWxpdHksIHRoZSBudW1iZXIgb2YgZGF0 YSBibG9ja3Mgc2hvdWxkIGJlIHdheSBiZWxvdyAyXjMyIGluIHRoaXMgc2l0dWF0aW9uLiZuYnNw OzwvcD4NCjxwPjxicj4NCjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij5I b3dldmVyLCB0aGUgY29uZmlkZW50aWFsaXR5IG9mIHRoZSBwbGFpbnRleHQgYmxvY2tzIGlzIG5v dCBsb3N0IGF0IGFsbCZuYnNwO2FzIGxvbmcgYXMgdGhlIGNvdW50ZXIgbnVtYmVyIGRvZXMgbm90 IHJlcGVhdC4mbmJzcDs8L3NwYW4+PGJyPg0KPC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTJwdDsiPjxicj4NCjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MnB0OyI+UXV5bmguJm5ic3A7PC9zcGFuPjwvcD4NCjxwPjxicj4NCjwvcD4NCjxwPjxicj4NCjwv cD4NCjxicj4NCjxicj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxociB0 YWJpbmRleD0iLTEiIHN0eWxlPSJkaXNwbGF5OmlubGluZS1ibG9jazsgd2lkdGg6OTglIj4NCjxk aXYgaWQ9ImRpdlJwbHlGd2RNc2ciIGRpcj0ibHRyIj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMt c2VyaWYiIGNvbG9yPSIjMDAwMDAwIiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxiPkZyb206PC9i PiBUTFMgJmx0OzxhIGhyZWY9Im1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZyI+dGxzLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmVrckBydGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDs8YnI+DQo8Yj5TZW50 OjwvYj4gV2VkbmVzZGF5LCBEZWNlbWJlciAxNiwgMjAxNSA2OjE3IEFNPGJyPg0KPGI+VG86PC9i PiBTaW1vbiBKb3NlZnNzb248YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0bHNAaWV0 Zi5vcmciPnRsc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIERh dGEgdm9sdW1lIGxpbWl0czwvZm9udD4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRp diBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFdlZCwgRGVjIDE2LCAyMDE1IGF0IDEyOjQ0IEFNLCBT aW1vbiBKb3NlZnNzb24gPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpzaW1v bkBqb3NlZnNzb24ub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ltb25Aam9zZWZzc29uLm9yZzwvYT4m Z3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOjFweDsgYm9y ZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7 IHBhZGRpbmctbGVmdDoxZXgiPg0KPHNwYW4gY2xhc3M9IiI+RXJpYyBSZXNjb3JsYSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JpdGVzOjxi cj4NCjxicj4NCiZndDsgV2F0c29uIGtpbmRseSBwcmVwYXJlZCBzb21lIHRleHQgdGhhdCBkZXNj cmliZWQgdGhlIGxpbWl0cyBvbiB3aGF0J3Mgc2FmZTxicj4NCiZndDsgZm9yIEFFUy1HQ00gYW5k IHJlc3RyaWN0aW5nIGFsbCBhbGdvcml0aG1zIHdpdGggVExTIDEuMyB0byB0aGF0IGxvd2VyPGJy Pg0KJmd0OyBsaW1pdCAoMl57MzZ9IGJ5dGVzKSwgZXZlbiB0aG91Z2ggQ2hhQ2hhIGRvZXNuJ3Qg aGF2ZSB0aGUgc2FtZTxicj4NCiZndDsgcmVzdHJpY3Rpb24uPGJyPg0KPGJyPg0KPC9zcGFuPkNh biB3ZSBzZWUgYSBicmllZiB3cml0ZXVwIGV4cGxhaW5pbmcgdGhlIDJeMzYgbnVtYmVyPzxicj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgYmVsaWV2ZSBXYXRzb24g cHJvdmlkZWQgb25lIGEgd2hpbGUgYmFjayBhdDo8L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90bHMvY3VycmVudC9tc2cxODI0MC5odG1s Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Rscy9jdXJyZW50L21zZzE4 MjQwLmh0bWw8L2E+PGJyPg0KPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBib3Jk ZXItbGVmdC13aWR0aDoxcHg7IGJvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7IGJv cmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCkkgZG9uJ3QgbGlrZSBy ZS1rZXlpbmcuJm5ic3A7IEl0IGlzIHVzdWFsbHkgYSBzaWduIHRoYXQgeW91ciBwcmltaXRpdmVz IGFyZTxicj4NCnRvbyB3ZWFrIGFuZCB5b3UgYXJlIGF0dGVtcHRpbmcgdG8gaGlkZSB0aGF0IGZh Y3QuJm5ic3A7IFRvIG1lLCBpdCBpcyBzaW1pbGFyPGJyPg0KdG8gZGlzY2FyZCB0aGUgZmlyc3Qg WCBieXRlIG9mIFJDNCBvdXRwdXQuPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+VG8gYmUgY2xlYXI6IEkgd291bGQgcHJlZmVyIG5vdCB0byByZWtleSBlaXRoZXIs IGJ1dCB0aGUgY29uc2Vuc3VzIGF0IElFVEYgWW9rb2hhbWE8L2Rpdj4NCjxkaXY+d2FzIHRoYXQg d2Ugd2VyZSBjbG9zZSBlbm91Z2ggdG8gdGhlIGxpbWl0IHRoYXQgd2UgcHJvYmFibHkgaGFkIHRv LiBXb3VsZCBiZTwvZGl2Pg0KPGRpdj5oYXBweSB0byBsZWFybiB0aGF0IHdlIGRpZG4ndC48L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi1Fa3I8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNz PSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxl ZnQtd2lkdGg6MXB4OyBib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpOyBib3JkZXIt bGVmdC1zdHlsZTpzb2xpZDsgcGFkZGluZy1sZWZ0OjFleCI+DQpJZiBBRVMtR0NNIGNhbm5vdCBw cm92aWRlIGNvbmZpZGVudGlhbGl0eSBiZXlvbmQgNjRHQiAod2hpY2ggd291bGQ8YnI+DQpzdXJw cmlzZSBtZSBzb21ld2hhdCksIEkgYmVsaWV2ZSB3ZSBvdWdodCB0byBiZSBjYXJlZnVsIGFib3V0 PGJyPg0KcmVjb21tZW5kaW5nIGl0Ljxicj4NCjxicj4NCk9mIGNvdXJzZSwgdGhlIGRldmlsIGlz IGluIHRoZSBkZXRhaWxzOiBpZiB0aGUgcmlzayBpcyB0aGF0IHRoZSBzZWNyZXQ8YnI+DQprZXkg aXMgbGVha2VkLCB0aGF0J3MgZmF0YWw7IGlmIHRoZSByaXNrIGlzIHRoYXQgdGhlIGF0dGFja2Vy IGNhbiB0ZWxsPGJyPg0Kd2hldGhlciB0d28gcGFydGljdWxhciBwbGFpbnRleHQgMTI4IGJ5dGUg YmxvY2tzIGFyZSB0aGUgc2FtZSBvciBub3QgaW48YnI+DQp0aGUgZW50aXJlIGZpbGUsIHRoYXQg Y2FuIGJlIGEgcmlzayB3ZSBjYW4gbGl2ZSB3aXRoIChzaW1pbGFyIHRvIHRoZTxicj4NCmRpc2Nh cmQgWCBieXRlcyBvZiBSQzQgZml4KS48YnI+DQo8YnI+DQpJIGJlbGlldmUgNjRHQiBpcyB3aXRo aW4gdGhlIHJhbmdlIHRoYXQgcGVvcGxlIGRvd25sb2FkIGluIGEgd2ViIGJyb3dzZXI8YnI+DQp0 aGVzZSBkYXlzLiZuYnNwOyBNb3JlIGRhdGEgaW50ZW5zaXZlIGxvbmdlci1ydW5uaW5nIHByb3Rv Y29scyBvZnRlbiB0cmFuc2Zlcjxicj4NCnNpZ25pZmljYW50bHkgbW9yZS48YnI+DQo8c3BhbiBj bGFzcz0iIj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+PGJyPg0KL1NpbW9uPGJyPg0KPC9mb250Pjwv c3Bhbj48L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_D296D6CB213C9urillmitedu_-- From nobody Wed Dec 16 07:50:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2441A0378 for ; Wed, 16 Dec 2015 07:50:17 -0800 (PST) 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 1nWSzRs4br7l for ; Wed, 16 Dec 2015 07:50:15 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096A31A0369 for ; Wed, 16 Dec 2015 07:50:15 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id u65so50578411qkh.2 for ; Wed, 16 Dec 2015 07:50:14 -0800 (PST) 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=ZzK0+vtpMQV5gL6HGzctKWCfP9O8LSPxAJMQK/i1qvY=; b=BVBp7HciizvI2/H1Ol8Pi7CDjZhOnAL+HlBwYb1Bc5Owx61AoKVUCxYIDgRicIbf8B xC9NDn8k/QAW7hXjGSEEjOEU0kWb0viKhZ5oeAYO2EEmV1sEQwYJOyoiJuWQlJ3PkIKJ 3bDuATX15wCgWRixlqHXJdaSkszjHXEUWfbB2q5iu+GP9JMblwpKuO34FPRIOsMd8AiF aEPYliiDpIKEIKd6e2G1WXft5H9X+/w3AHl7shNiqXq1AZiX5M3vGPulsi7r5sgy/ycE OuYOK74TMmDS2JknwaDoZEW2Fn83YoZkqVLYUD2+JGlOkgVsdGiktBxI9Iz++1p1Z9aT JaxQ== MIME-Version: 1.0 X-Received: by 10.129.57.135 with SMTP id g129mr26876038ywa.244.1450281014049; Wed, 16 Dec 2015 07:50:14 -0800 (PST) Received: by 10.129.148.131 with HTTP; Wed, 16 Dec 2015 07:50:13 -0800 (PST) In-Reply-To: References: <87twnibx5p.fsf@latte.josefsson.org> Date: Wed, 16 Dec 2015 10:50:13 -0500 Message-ID: From: Watson Ladd To: "Blumenthal, Uri - 0553 - MITLL" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 15:50:17 -0000 On Wed, Dec 16, 2015 at 10:44 AM, Blumenthal, Uri - 0553 - MITLL wrote: > OK, let me try an extremely na=C3=AFve approach. > > Say, an adversary observes a ton of TLS traffic between A and B. Using > approach that Watson and others outlined, he can now tell that this is no= t a > truly random stream but a bunch of encrypted data. My question is, from > practical real-world point of view - so what? (Of course, beyond the abil= ity > to publish a real paper that IND-* has been compromised :) > > If there are practical consequences, like loss of confidentiality =E2=80= =93 I=E2=80=99m > dying to hear the outline of a practical attack. The problem is that people design systems assuming something like indistinguishability. And so when you violate that assumption, all bets are off. What is the actual problem with either implementing rekeying, or limiting data to something like 128 GByte per connection? > -- > Regards, > Uri Blumenthal > > From: TLS on behalf of "Dang, Quynh" > > Date: Wednesday, December 16, 2015 at 07:21 > To: Eric Rescorla , "tls@ietf.org" > > Subject: Re: [TLS] Data volume limits > > Hi Eric, > > > I explained the issue before and some other people recently explained it > again on this thread. AES has 128-bit block. Therefore, when there are 2^= 64 > or more ciphertext blocks, there are likely collisions among the cipherte= xt > blocks (the collision probability increases rapidly when the number of > ciphertext blocks increases above 2^64 ( 2^n/2 in generic term) ). > > > However, the only information the attacker can gain from ANY pair of > collided ciphertext blocks is that their corresponding plaintext blocks a= re > probably different ones because the chance for them to be the same is > 1/2^128 (1/2^n in generic term) and this is NOT better than a random gues= s. > So, you don't lose anything actually. > > > As a pseudorandom function, AES completely fails under any mode when the > number of ciphertext blocks gets above 2^64. When the counter is > effectively only 64 bits (instead of 96 bits as in TLS 1.3), the data > complexity should be below 2^32 blocks because the same input block and t= he > same key can be repeated 2^32 times to find a collision in the ciphertext > blocks. If you want a negligible collision probability, the number of da= ta > blocks should be way below 2^32 in this situation. > > > However, the confidentiality of the plaintext blocks is not lost at all a= s > long as the counter number does not repeat. > > > Quynh. > > > > > > ________________________________ > From: TLS on behalf of Eric Rescorla > Sent: Wednesday, December 16, 2015 6:17 AM > To: Simon Josefsson > Cc: tls@ietf.org > Subject: Re: [TLS] Data volume limits > > > > On Wed, Dec 16, 2015 at 12:44 AM, Simon Josefsson > wrote: >> >> Eric Rescorla writes: >> >> > Watson kindly prepared some text that described the limits on what's >> > safe >> > for AES-GCM and restricting all algorithms with TLS 1.3 to that lower >> > limit (2^{36} bytes), even though ChaCha doesn't have the same >> > restriction. >> >> Can we see a brief writeup explaining the 2^36 number? > > > I believe Watson provided one a while back at: > https://www.ietf.org/mail-archive/web/tls/current/msg18240.html > >> >> I don't like re-keying. It is usually a sign that your primitives are >> too weak and you are attempting to hide that fact. To me, it is similar >> to discard the first X byte of RC4 output. > > > To be clear: I would prefer not to rekey either, but the consensus at IET= F > Yokohama > was that we were close enough to the limit that we probably had to. Would= be > happy to learn that we didn't. > > -Ekr > > > >> If AES-GCM cannot provide confidentiality beyond 64GB (which would >> surprise me somewhat), I believe we ought to be careful about >> recommending it. >> >> Of course, the devil is in the details: if the risk is that the secret >> key is leaked, that's fatal; if the risk is that the attacker can tell >> whether two particular plaintext 128 byte blocks are the same or not in >> the entire file, that can be a risk we can live with (similar to the >> discard X bytes of RC4 fix). >> >> I believe 64GB is within the range that people download in a web browser >> these days. More data intensive longer-running protocols often transfer >> significantly more. >> >> /Simon > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Dec 16 08:12:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9061A0397 for ; Wed, 16 Dec 2015 08:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, 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 P5QX_kSlBC6L for ; Wed, 16 Dec 2015 08:12:50 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946EA1A1B22 for ; Wed, 16 Dec 2015 08:12:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1389; q=dns/txt; s=iport; t=1450282332; x=1451491932; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=Dam+1YEDcu7jtp4ZBuRnTO3kkWC8pUcgR7uFA81wsao=; b=l6GNnysyINzgyhUG1yA4hf5RI3cH+ENfNx9gzixv4sEKLD6AAGltl69p ykXE3xKi7RGf7dGknzlZovW0vPkPmacJEVvw0KbaCl4WKnOZHLtPYEwr6 edx6Z0Krf8Mt7v+C55O93OgV5GpkmfGz+bfmP4/5l9wzrQCxh2hMW35Rd 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHBQAsjHFW/4cNJK1egzpSvmWBYyGHF?= =?us-ascii?q?zoSAQEBAQEBAYEKhF4VQDYCBRYLAgsDAgECAVgIAQGIKw6cOY9wkhABCx0EgQG?= =?us-ascii?q?NQ4FRZYJQgUkFjiyIUIEMhC2CcYUeiSaTdSgEN4QihTUBAQE?= X-IronPort-AV: E=Sophos;i="5.20,437,1444694400"; d="scan'208";a="218636863" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Dec 2015 16:12:11 +0000 Received: from [64.102.56.172] (dhcp-64-102-56-172.cisco.com [64.102.56.172]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tBGGCB31025844 for ; Wed, 16 Dec 2015 16:12:11 GMT From: John Foley To: tls@ietf.org Message-ID: <56718D7A.4000302@cisco.com> Date: Wed, 16 Dec 2015 11:12:42 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] Explicit use of client and server random values X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2015 16:12:52 -0000 I apologize if this topic was previously discussed, I've only recently joined the TLS mailer list. While reviewing the TLS 1.3 draft (revision 10), section 7 begins with the following wording: In order to begin connection protection, the TLS Record Protocol requires specification of a suite of algorithms, a master secret, and the client and server random values. However, when reading through all of section 7, there appears to be no explicit use for the client and server random values. While these values would be used implicitly when the handshake messages are hashed, and thus have bearing on the key schedule calculation, there appears to be no explicit use of the client and server random values similar to section 6.3 in the TLS 1.2 spec. Am I interpreting this properly? If the client and server random values are no longer explicitly used in any key derivation logic, maybe this should be noted in section 6.3.1, as implementors will no longer need to parse these values when processing incoming messages. Additionally, the intro to section 7 is misleading to implementors, as it implies the client and server random values are needed to derive the key schedule. The following issue and PR appear to be related to my question: https://github.com/tlswg/tls13-spec/issues/185 https://github.com/tlswg/tls13-spec/pull/189 From nobody Wed Dec 16 09:09:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECF51A1B7F for ; Wed, 16 Dec 2015 09:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 1qGtrX7IzUE2 for ; Wed, 16 Dec 2015 09:09:38 -0800 (PST) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id E79291A6FF7 for ; Wed, 16 Dec 2015 09:09:36 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id tBGH9ZnJ030387; Wed, 16 Dec 2015 12:09:35 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Watson Ladd Thread-Topic: [TLS] Data volume limits Thread-Index: AQHRN33Tde9nh48KlkmRxpLGJ4HFm57NTcOpgAB95gCAABHcgP//xuuAgABzTID//8JOAA== Date: Wed, 16 Dec 2015 17:09:34 +0000 Message-ID: References: <87twnibx5p.fsf@latte.josefsson.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-originating-ip: [172.25.177.65] Content-Type: text/plain; charset="utf-8" Content-ID: <5A0C0F1B5BCD7C4490147929F123815C@ll.mit.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2015-12-16_07:2015-12-16,2015-12-16,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-1511060000 definitions=main-1512160288 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 17:09:41 -0000 T24gMTIvMTYvMTUsIDEwOjUwLCAiV2F0c29uIExhZGQiIDx3YXRzb25ibGFkZEBnbWFpbC5jb20+ IHdyb3RlOg0KDQo+T24gV2VkLCBEZWMgMTYsIDIwMTUgYXQgMTA6NDQgQU0sIEJsdW1lbnRoYWws IFVyaSAtIDA1NTMgLSBNSVRMTA0KPjx1cmlAbGwubWl0LmVkdT4gd3JvdGU6DQo+PiBPSywgbGV0 IG1lIHRyeSBhbiBleHRyZW1lbHkgbmHDr3ZlIGFwcHJvYWNoLg0KPj4NCj4+IFNheSwgYW4gYWR2 ZXJzYXJ5IG9ic2VydmVzIGEgdG9uIG9mIFRMUyB0cmFmZmljIGJldHdlZW4gQSBhbmQgQi4gVXNp bmcNCj4+IGFwcHJvYWNoIHRoYXQgV2F0c29uIGFuZCBvdGhlcnMgb3V0bGluZWQsIGhlIGNhbiBu b3cgdGVsbCB0aGF0IHRoaXMgaXMNCj4+bm90IGENCj4+IHRydWx5IHJhbmRvbSBzdHJlYW0gYnV0 IGEgYnVuY2ggb2YgZW5jcnlwdGVkIGRhdGEuIE15IHF1ZXN0aW9uIGlzLCBmcm9tDQo+PiBwcmFj dGljYWwgcmVhbC13b3JsZCBwb2ludCBvZiB2aWV3IC0gc28gd2hhdD8gKE9mIGNvdXJzZSwgYmV5 b25kIHRoZQ0KPj5hYmlsaXR5DQo+PiB0byBwdWJsaXNoIGEgcmVhbCBwYXBlciB0aGF0IElORC0q IGhhcyBiZWVuIGNvbXByb21pc2VkIDopDQo+Pg0KPj4gSWYgdGhlcmUgYXJlIHByYWN0aWNhbCBj b25zZXF1ZW5jZXMsIGxpa2UgbG9zcyBvZiBjb25maWRlbnRpYWxpdHkg4oCTIEnigJltDQo+PiBk eWluZyB0byBoZWFyIHRoZSBvdXRsaW5lIG9mIGEgcHJhY3RpY2FsIGF0dGFjay4NCj4NCj5UaGUg cHJvYmxlbSBpcyB0aGF0IHBlb3BsZSBkZXNpZ24gc3lzdGVtcyBhc3N1bWluZyBzb21ldGhpbmcg bGlrZQ0KPmluZGlzdGluZ3Vpc2hhYmlsaXR5LiBBbmQgc28gd2hlbiB5b3UgdmlvbGF0ZSB0aGF0 IGFzc3VtcHRpb24sIGFsbA0KPmJldHMgYXJlIG9mZi4NCg0KSSBkb27igJl0IGJ1eSB0aGlzLiBB RkFJSywgVExTIGhhcyBub3QgYmVlbiBkZXNpZ25lZCBiYXNlZCBvbiB0aGF0DQphc3N1bXB0aW9u LiBBbmQgSeKAmW0gbm90IG1ha2luZyBhbnkgYmV0cy4gOikNCg0KQnV0Og0KDQo+V2hhdCBpcyB0 aGUgYWN0dWFsIHByb2JsZW0gd2l0aCBlaXRoZXIgaW1wbGVtZW50aW5nIHJla2V5aW5nLCBvcg0K PmxpbWl0aW5nIGRhdGEgdG8gc29tZXRoaW5nIGxpa2UgMTI4IEdCeXRlIHBlciBjb25uZWN0aW9u Pw0KDQpBcyBmYXIgYXMgSeKAmW0gY29uY2VybmVkIC0gbm9uZSAobm8gcHJvYmxlbSkuIEFuZCBp ZiB0aGVyZeKAmXMgYSB3YXkgdG8NCmVuZm9yY2UgcmVrZXlpbmcgc29vbmVyIHRoYW4gdGhhdCAo bGltaXRpbmcgZGF0YS11bmRlci1vbmUta2V5IHRvIGEgTVVDSA0Kc21hbGxlciBhbW91bnQpIC0g SeKAmWQgYmUgaW4gZmF2b3Igb2YgdGhhdCB0b28uIEkganVzdCBkb27igJl0IGFjY2VwdCB0aGUN CmFib3ZlIGp1c3RpZmljYXRpb24gZm9yIGl0IC0gYW5kIHdhbnQgdG8gYmUgc2hvd24gaG93IGxv c3Mgb2YgSU5EIHByb3BlcnR5DQppbiBUTFMgY29udGV4dCBsZWFkcyB0byBhIHByYWN0aWNhbCBh dHRhY2suDQoNCg0KPj5Gcm9tOiBUTFMgPHRscy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYg b2YgIkRhbmcsIFF1eW5oIg0KPj4gPHF1eW5oLmRhbmdAbmlzdC5nb3Y+DQo+PiBEYXRlOiBXZWRu ZXNkYXksIERlY2VtYmVyIDE2LCAyMDE1IGF0IDA3OjIxDQo+PiBUbzogRXJpYyBSZXNjb3JsYSA8 ZWtyQHJ0Zm0uY29tPiwgInRsc0BpZXRmLm9yZyIgPHRsc0BpZXRmLm9yZz4NCj4+DQo+PiBTdWJq ZWN0OiBSZTogW1RMU10gRGF0YSB2b2x1bWUgbGltaXRzDQo+Pg0KPj4gSGkgRXJpYywNCj4+DQo+ Pg0KPj4gSSBleHBsYWluZWQgdGhlIGlzc3VlIGJlZm9yZSBhbmQgc29tZSBvdGhlciBwZW9wbGUg cmVjZW50bHkgZXhwbGFpbmVkIGl0DQo+PiBhZ2FpbiBvbiB0aGlzIHRocmVhZC4gQUVTIGhhcyAx MjgtYml0IGJsb2NrLiBUaGVyZWZvcmUsIHdoZW4gdGhlcmUgYXJlDQo+PjJeNjQNCj4+IG9yIG1v cmUgY2lwaGVydGV4dCBibG9ja3MsIHRoZXJlIGFyZSBsaWtlbHkgY29sbGlzaW9ucyBhbW9uZyB0 aGUNCj4+Y2lwaGVydGV4dA0KPj4gYmxvY2tzICh0aGUgY29sbGlzaW9uIHByb2JhYmlsaXR5IGlu Y3JlYXNlcyByYXBpZGx5IHdoZW4gdGhlIG51bWJlciBvZg0KPj4gY2lwaGVydGV4dCBibG9ja3Mg aW5jcmVhc2VzIGFib3ZlIDJeNjQgKCAyXm4vMiBpbiBnZW5lcmljIHRlcm0pICkuDQo+Pg0KPj4N Cj4+IEhvd2V2ZXIsIHRoZSBvbmx5IGluZm9ybWF0aW9uIHRoZSBhdHRhY2tlciBjYW4gZ2FpbiBm cm9tIEFOWSBwYWlyIG9mDQo+PiBjb2xsaWRlZCBjaXBoZXJ0ZXh0IGJsb2NrcyBpcyB0aGF0IHRo ZWlyIGNvcnJlc3BvbmRpbmcgcGxhaW50ZXh0IGJsb2Nrcw0KPj5hcmUNCj4+IHByb2JhYmx5IGRp ZmZlcmVudCBvbmVzIGJlY2F1c2UgdGhlIGNoYW5jZSBmb3IgdGhlbSB0byBiZSB0aGUgc2FtZSBp cw0KPj4gMS8yXjEyOCAoMS8yXm4gaW4gZ2VuZXJpYyB0ZXJtKSBhbmQgdGhpcyBpcyBOT1QgYmV0 dGVyIHRoYW4gYSByYW5kb20NCj4+Z3Vlc3MuDQo+PiBTbywgeW91IGRvbid0IGxvc2UgYW55dGhp bmcgYWN0dWFsbHkuDQo+Pg0KPj4NCj4+IEFzIGEgcHNldWRvcmFuZG9tIGZ1bmN0aW9uLCBBRVMg Y29tcGxldGVseSBmYWlscyB1bmRlciBhbnkgbW9kZSB3aGVuIHRoZQ0KPj4gbnVtYmVyIG9mIGNp cGhlcnRleHQgYmxvY2tzIGdldHMgYWJvdmUgMl42NC4gIFdoZW4gdGhlIGNvdW50ZXIgaXMNCj4+ IGVmZmVjdGl2ZWx5IG9ubHkgNjQgYml0cyAoaW5zdGVhZCBvZiA5NiBiaXRzIGFzIGluIFRMUyAx LjMpLCB0aGUgZGF0YQ0KPj4gY29tcGxleGl0eSBzaG91bGQgYmUgYmVsb3cgMl4zMiBibG9ja3Mg YmVjYXVzZSB0aGUgc2FtZSBpbnB1dCBibG9jayBhbmQNCj4+dGhlDQo+PiBzYW1lIGtleSBjYW4g YmUgcmVwZWF0ZWQgMl4zMiB0aW1lcyB0byBmaW5kIGEgY29sbGlzaW9uIGluIHRoZQ0KPj5jaXBo ZXJ0ZXh0DQo+PiBibG9ja3MuICBJZiB5b3Ugd2FudCBhIG5lZ2xpZ2libGUgY29sbGlzaW9uIHBy b2JhYmlsaXR5LCB0aGUgbnVtYmVyIG9mDQo+PmRhdGENCj4+IGJsb2NrcyBzaG91bGQgYmUgd2F5 IGJlbG93IDJeMzIgaW4gdGhpcyBzaXR1YXRpb24uDQo+Pg0KPj4NCj4+IEhvd2V2ZXIsIHRoZSBj b25maWRlbnRpYWxpdHkgb2YgdGhlIHBsYWludGV4dCBibG9ja3MgaXMgbm90IGxvc3QgYXQgYWxs DQo+PmFzDQo+PiBsb25nIGFzIHRoZSBjb3VudGVyIG51bWJlciBkb2VzIG5vdCByZXBlYXQuDQo+ Pg0KPj4NCj4+IFF1eW5oLg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gRnJvbTogVExTIDx0bHMtYm91bmNlc0BpZXRmLm9yZz4gb24g YmVoYWxmIG9mIEVyaWMgUmVzY29ybGENCj4+PGVrckBydGZtLmNvbT4NCj4+IFNlbnQ6IFdlZG5l c2RheSwgRGVjZW1iZXIgMTYsIDIwMTUgNjoxNyBBTQ0KPj4gVG86IFNpbW9uIEpvc2Vmc3Nvbg0K Pj4gQ2M6IHRsc0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtUTFNdIERhdGEgdm9sdW1lIGxp bWl0cw0KPj4NCj4+DQo+Pg0KPj4gT24gV2VkLCBEZWMgMTYsIDIwMTUgYXQgMTI6NDQgQU0sIFNp bW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9zZWZzc29uLm9yZz4NCj4+IHdyb3RlOg0KPj4+DQo+Pj4g RXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPiB3cml0ZXM6DQo+Pj4NCj4+PiA+IFdhdHNvbiBr aW5kbHkgcHJlcGFyZWQgc29tZSB0ZXh0IHRoYXQgZGVzY3JpYmVkIHRoZSBsaW1pdHMgb24gd2hh dCdzDQo+Pj4gPiBzYWZlDQo+Pj4gPiBmb3IgQUVTLUdDTSBhbmQgcmVzdHJpY3RpbmcgYWxsIGFs Z29yaXRobXMgd2l0aCBUTFMgMS4zIHRvIHRoYXQgbG93ZXINCj4+PiA+IGxpbWl0ICgyXnszNn0g Ynl0ZXMpLCBldmVuIHRob3VnaCBDaGFDaGEgZG9lc24ndCBoYXZlIHRoZSBzYW1lDQo+Pj4gPiBy ZXN0cmljdGlvbi4NCj4+Pg0KPj4+IENhbiB3ZSBzZWUgYSBicmllZiB3cml0ZXVwIGV4cGxhaW5p bmcgdGhlIDJeMzYgbnVtYmVyPw0KPj4NCj4+DQo+PiBJIGJlbGlldmUgV2F0c29uIHByb3ZpZGVk IG9uZSBhIHdoaWxlIGJhY2sgYXQ6DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL3Rscy9jdXJyZW50L21zZzE4MjQwLmh0bWwNCj4+DQo+Pj4NCj4+PiBJIGRvbid0IGxp a2UgcmUta2V5aW5nLiAgSXQgaXMgdXN1YWxseSBhIHNpZ24gdGhhdCB5b3VyIHByaW1pdGl2ZXMg YXJlDQo+Pj4gdG9vIHdlYWsgYW5kIHlvdSBhcmUgYXR0ZW1wdGluZyB0byBoaWRlIHRoYXQgZmFj dC4gIFRvIG1lLCBpdCBpcw0KPj4+c2ltaWxhcg0KPj4+IHRvIGRpc2NhcmQgdGhlIGZpcnN0IFgg Ynl0ZSBvZiBSQzQgb3V0cHV0Lg0KPj4NCj4+DQo+PiBUbyBiZSBjbGVhcjogSSB3b3VsZCBwcmVm ZXIgbm90IHRvIHJla2V5IGVpdGhlciwgYnV0IHRoZSBjb25zZW5zdXMgYXQNCj4+SUVURg0KPj4g WW9rb2hhbWENCj4+IHdhcyB0aGF0IHdlIHdlcmUgY2xvc2UgZW5vdWdoIHRvIHRoZSBsaW1pdCB0 aGF0IHdlIHByb2JhYmx5IGhhZCB0by4NCj4+V291bGQgYmUNCj4+IGhhcHB5IHRvIGxlYXJuIHRo YXQgd2UgZGlkbid0Lg0KPj4NCj4+IC1Fa3INCj4+DQo+Pg0KPj4NCj4+PiBJZiBBRVMtR0NNIGNh bm5vdCBwcm92aWRlIGNvbmZpZGVudGlhbGl0eSBiZXlvbmQgNjRHQiAod2hpY2ggd291bGQNCj4+ PiBzdXJwcmlzZSBtZSBzb21ld2hhdCksIEkgYmVsaWV2ZSB3ZSBvdWdodCB0byBiZSBjYXJlZnVs IGFib3V0DQo+Pj4gcmVjb21tZW5kaW5nIGl0Lg0KPj4+DQo+Pj4gT2YgY291cnNlLCB0aGUgZGV2 aWwgaXMgaW4gdGhlIGRldGFpbHM6IGlmIHRoZSByaXNrIGlzIHRoYXQgdGhlIHNlY3JldA0KPj4+ IGtleSBpcyBsZWFrZWQsIHRoYXQncyBmYXRhbDsgaWYgdGhlIHJpc2sgaXMgdGhhdCB0aGUgYXR0 YWNrZXIgY2FuIHRlbGwNCj4+PiB3aGV0aGVyIHR3byBwYXJ0aWN1bGFyIHBsYWludGV4dCAxMjgg Ynl0ZSBibG9ja3MgYXJlIHRoZSBzYW1lIG9yIG5vdCBpbg0KPj4+IHRoZSBlbnRpcmUgZmlsZSwg dGhhdCBjYW4gYmUgYSByaXNrIHdlIGNhbiBsaXZlIHdpdGggKHNpbWlsYXIgdG8gdGhlDQo+Pj4g ZGlzY2FyZCBYIGJ5dGVzIG9mIFJDNCBmaXgpLg0KPj4+DQo+Pj4gSSBiZWxpZXZlIDY0R0IgaXMg d2l0aGluIHRoZSByYW5nZSB0aGF0IHBlb3BsZSBkb3dubG9hZCBpbiBhIHdlYg0KPj4+YnJvd3Nl cg0KPj4+IHRoZXNlIGRheXMuICBNb3JlIGRhdGEgaW50ZW5zaXZlIGxvbmdlci1ydW5uaW5nIHBy b3RvY29scyBvZnRlbg0KPj4+dHJhbnNmZXINCj4+PiBzaWduaWZpY2FudGx5IG1vcmUuDQo+Pj4N Cj4+PiAvU2ltb24NCj4+DQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiBUTFMgbWFpbGluZyBsaXN0DQo+PiBUTFNAaWV0Zi5vcmcN Cj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo+Pg0KPg0KPg0K Pg0KPi0tIA0KPiJNYW4gaXMgYm9ybiBmcmVlLCBidXQgZXZlcnl3aGVyZSBoZSBpcyBpbiBjaGFp bnMiLg0KPi0tUm91c3NlYXUuDQo+DQoNCg== From nobody Wed Dec 16 09:16:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D136B1A1C04 for ; Wed, 16 Dec 2015 09:16:54 -0800 (PST) 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 hWuI3LHnatHf for ; Wed, 16 Dec 2015 09:16:45 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 347301A6EDA for ; Wed, 16 Dec 2015 09:16:43 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id u65so55255992qkh.2 for ; Wed, 16 Dec 2015 09:16:43 -0800 (PST) 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=TeEW5Y6wImLRQan7msjDnmsH0NMr/8UjpcC6Se5ojE8=; b=0/75RBLBblekViF3nbq57epxZ2hBjIq1JNmAIbOhBPd1byJcoQ4zczwxOaCi90+Mrr LPP5/vsLODQSvuj2MPIhQ9uDsy/iL7yZrx1BHQzauKczfh7C6b/BidET6bn+YbgcphO1 VNax/X9Yt6vCyqY/CbO71J+QsyD3w7dQLDAsjZvZJFOaLdcTUAk0tEPbRu0Kk9TQaU4U UmCFLo3vaI7ctwSX8g8a9tKymazof7t3Efxp9j88Q1L58GvC9mLaNCyus7zt3LH/0i3M inF8TN5AsLpG7oBeaMCRnmkl2BYMc+Qd6hOP8fwbO8B7U4AnBdIEpLsLvSq79b+p+d0m O5oA== MIME-Version: 1.0 X-Received: by 10.129.57.135 with SMTP id g129mr27253994ywa.244.1450286201589; Wed, 16 Dec 2015 09:16:41 -0800 (PST) Received: by 10.129.148.131 with HTTP; Wed, 16 Dec 2015 09:16:41 -0800 (PST) In-Reply-To: References: <87twnibx5p.fsf@latte.josefsson.org> Date: Wed, 16 Dec 2015 12:16:41 -0500 Message-ID: From: Watson Ladd To: "Blumenthal, Uri - 0553 - MITLL" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 17:16:55 -0000 On Wed, Dec 16, 2015 at 12:09 PM, Blumenthal, Uri - 0553 - MITLL wrote: > On 12/16/15, 10:50, "Watson Ladd" wrote: > >>On Wed, Dec 16, 2015 at 10:44 AM, Blumenthal, Uri - 0553 - MITLL >> wrote: >>> OK, let me try an extremely na=C3=AFve approach. >>> >>> Say, an adversary observes a ton of TLS traffic between A and B. Using >>> approach that Watson and others outlined, he can now tell that this is >>>not a >>> truly random stream but a bunch of encrypted data. My question is, from >>> practical real-world point of view - so what? (Of course, beyond the >>>ability >>> to publish a real paper that IND-* has been compromised :) >>> >>> If there are practical consequences, like loss of confidentiality =E2= =80=93 I=E2=80=99m >>> dying to hear the outline of a practical attack. >> >>The problem is that people design systems assuming something like >>indistinguishability. And so when you violate that assumption, all >>bets are off. > > I don=E2=80=99t buy this. AFAIK, TLS has not been designed based on that > assumption. And I=E2=80=99m not making any bets. :) What security properties does TLS provide? In the past TLS users have made assumptions that TLS provides security properties it does not. The solution to this problem is to provide the security properties that people expect, and they expect IND. > > But: > >>What is the actual problem with either implementing rekeying, or >>limiting data to something like 128 GByte per connection? > > As far as I=E2=80=99m concerned - none (no problem). And if there=E2=80= =99s a way to > enforce rekeying sooner than that (limiting data-under-one-key to a MUCH > smaller amount) - I=E2=80=99d be in favor of that too. I just don=E2=80= =99t accept the > above justification for it - and want to be shown how loss of IND propert= y > in TLS context leads to a practical attack. The practical attack is the loss of IND property. That's the attack. This is not a weakness in the proven bounds, but a mode limitation. Since you've agreed we can rekey more frequently > > >>>From: TLS on behalf of "Dang, Quynh" >>> >>> Date: Wednesday, December 16, 2015 at 07:21 >>> To: Eric Rescorla , "tls@ietf.org" >>> >>> Subject: Re: [TLS] Data volume limits >>> >>> Hi Eric, >>> >>> >>> I explained the issue before and some other people recently explained i= t >>> again on this thread. AES has 128-bit block. Therefore, when there are >>>2^64 >>> or more ciphertext blocks, there are likely collisions among the >>>ciphertext >>> blocks (the collision probability increases rapidly when the number of >>> ciphertext blocks increases above 2^64 ( 2^n/2 in generic term) ). >>> >>> >>> However, the only information the attacker can gain from ANY pair of >>> collided ciphertext blocks is that their corresponding plaintext blocks >>>are >>> probably different ones because the chance for them to be the same is >>> 1/2^128 (1/2^n in generic term) and this is NOT better than a random >>>guess. >>> So, you don't lose anything actually. >>> >>> >>> As a pseudorandom function, AES completely fails under any mode when th= e >>> number of ciphertext blocks gets above 2^64. When the counter is >>> effectively only 64 bits (instead of 96 bits as in TLS 1.3), the data >>> complexity should be below 2^32 blocks because the same input block and >>>the >>> same key can be repeated 2^32 times to find a collision in the >>>ciphertext >>> blocks. If you want a negligible collision probability, the number of >>>data >>> blocks should be way below 2^32 in this situation. >>> >>> >>> However, the confidentiality of the plaintext blocks is not lost at all >>>as >>> long as the counter number does not repeat. >>> >>> >>> Quynh. >>> >>> >>> >>> >>> >>> ________________________________ >>> From: TLS on behalf of Eric Rescorla >>> >>> Sent: Wednesday, December 16, 2015 6:17 AM >>> To: Simon Josefsson >>> Cc: tls@ietf.org >>> Subject: Re: [TLS] Data volume limits >>> >>> >>> >>> On Wed, Dec 16, 2015 at 12:44 AM, Simon Josefsson >>> wrote: >>>> >>>> Eric Rescorla writes: >>>> >>>> > Watson kindly prepared some text that described the limits on what's >>>> > safe >>>> > for AES-GCM and restricting all algorithms with TLS 1.3 to that lowe= r >>>> > limit (2^{36} bytes), even though ChaCha doesn't have the same >>>> > restriction. >>>> >>>> Can we see a brief writeup explaining the 2^36 number? >>> >>> >>> I believe Watson provided one a while back at: >>> https://www.ietf.org/mail-archive/web/tls/current/msg18240.html >>> >>>> >>>> I don't like re-keying. It is usually a sign that your primitives are >>>> too weak and you are attempting to hide that fact. To me, it is >>>>similar >>>> to discard the first X byte of RC4 output. >>> >>> >>> To be clear: I would prefer not to rekey either, but the consensus at >>>IETF >>> Yokohama >>> was that we were close enough to the limit that we probably had to. >>>Would be >>> happy to learn that we didn't. >>> >>> -Ekr >>> >>> >>> >>>> If AES-GCM cannot provide confidentiality beyond 64GB (which would >>>> surprise me somewhat), I believe we ought to be careful about >>>> recommending it. >>>> >>>> Of course, the devil is in the details: if the risk is that the secret >>>> key is leaked, that's fatal; if the risk is that the attacker can tell >>>> whether two particular plaintext 128 byte blocks are the same or not i= n >>>> the entire file, that can be a risk we can live with (similar to the >>>> discard X bytes of RC4 fix). >>>> >>>> I believe 64GB is within the range that people download in a web >>>>browser >>>> these days. More data intensive longer-running protocols often >>>>transfer >>>> significantly more. >>>> >>>> /Simon >>> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> >> >>-- >>"Man is born free, but everywhere he is in chains". >>--Rousseau. >> > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Dec 16 10:14:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E5C1A8732 for ; Wed, 16 Dec 2015 10:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 Mt2zfBg7_luS for ; Wed, 16 Dec 2015 10:14:13 -0800 (PST) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 56A711A8725 for ; Wed, 16 Dec 2015 10:14:12 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id tBGIDv8I006955; Wed, 16 Dec 2015 13:14:04 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Watson Ladd Thread-Topic: [TLS] Data volume limits Thread-Index: AQHRN33Tde9nh48KlkmRxpLGJ4HFm57NTcOpgAB95gCAABHcgP//xuuAgABzTID//8JOAIAAVduA//+8KgA= Date: Wed, 16 Dec 2015 18:14:00 +0000 Message-ID: References: <87twnibx5p.fsf@latte.josefsson.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.5.8.151023 x-originating-ip: [172.25.177.51] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3533116434_47352718" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2015-12-16_07:2015-12-16,2015-12-16,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-1511060000 definitions=main-1512160300 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 18:14:16 -0000 --B_3533116434_47352718 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 12/16/15, 12:16 , "Watson Ladd" wrote: >On Wed, Dec 16, 2015 at 12:09 PM, Blumenthal, Uri - 0553 - MITLL > wrote: >> On 12/16/15, 10:50, "Watson Ladd" wrote: >>>>If there are practical consequences, like loss of confidentiality =E2=80=93 I= =E2=80=99m >>>> dying to hear the outline of a practical attack. >>> >>>The problem is that people design systems assuming something like >>>indistinguishability. And so when you violate that assumption, all >>>bets are off. >> >> I don=E2=80=99t buy this. AFAIK, TLS has not been designed based on that >> assumption. And I=E2=80=99m not making any bets. :) > >What security properties does TLS provide? When the vast majority of TLS users employ it (TLS), they expect (a) that TLS would ensure the authenticity of their remote peer, (b) that TLS would protect their data exchange from being eavesdropped on and/or modified, and (c) that these hold even when the =E2=80=9Cenemy=E2=80=9D (whoever he might be) controls the entire communications path between them and their peers. You can translate the above into more formal definition. :-) >In the past TLS users have made assumptions that TLS provides security >properties it does not. Very true. >The solution to this problem is to provide the security properties >that people expect, and they expect IND. Not necessarily so. As far as I=E2=80=99m concerned, IND-* is a good property to have, but not a =E2=80=9Csacred cow=E2=80=9D.=20 >>>What is the actual problem with either implementing rekeying, or >>>limiting data to something like 128 GByte per connection? >> >> As far as I=E2=80=99m concerned - none (no problem). And if there=E2=80=99s a way to >> enforce rekeying sooner than that (limiting data-under-one-key to a MUCH >> smaller amount) - I=E2=80=99d be in favor of that too. I just don=E2=80=99t accept t= he >> above justification for it - and want to be shown how loss of IND >>property >> in TLS context leads to a practical attack. > >The practical attack is the loss of IND property. That's the attack. And how does it translate into a loss of one or more of the above properties? That=E2=80=99s what people want to hear. If you tell them that an observer would be able to mathematically distinguish between truly random data and their encrypted TLS stream (but only after 2^n blocks passed by, and that=E2=80=99s their risk and exposure) - they=E2=80=99re likely to laugh you out o= f the room. >This is not a weakness in the proven bounds, but a mode limitation. >Since you've agreed we can rekey more frequently Yes I agree that we can, and probably should. Probably regardless of the mode used, to keep things simple(r). --B_3533116434_47352718 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ0AYJKoZIhvcNAQcCoIIQwTCCEL0CAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKE5SxSwAAAABE8TANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1MDYxNTE2MjQzOVoXDTE2MDYxNDE2MjQzOVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC0tVFZOYvbDipiXfjylg0yIORem8AMZ4UQJ7EM2BI8 jKLj/h3RwH4w2DOMdepALLUqscSrpX6HPbo80M1O0cSSIYcYl8wQzDAMmvoD3HWbupwSXEPf eRtBo26jAvsDkOp46TPu40Pu61AkHx4vIgqU7XkofKhow18Ka/9ZkJ+oSnLK6Xy9+n8JiViO kTm2NjyF+CcpAobwZ3lBepHihvK3EilYR6V1EHQb+Y+2aWtexkFzBNXaN7i4Sdzq+LNSzCON DDDnRxA2c/B/p7MBDzocaigPxmKOHcE5eamxCgpJEUVCEALzeVZxcYURDJw68tZ90pJSLuw7 r6iigykQbRINAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUQzxm8xAhtcoaGyRStaMMhrmd7/Mw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAI8vbC+RZJEH0jhe5e9w F18xYCquDo5kxkoD83qYcVPVFYPnjuAvZ6o9ENa3F0GiAjFVm6HcUbm0zeWT6ZDYIrbh7GRM 4IO8pD9ziwvLIx8rvLvUhiBpsZvznVOWX1yGC0UkIKyiseAszczAYFVJonKB8jDRnxgFlPlo mFUaDtjL86cyp+pHc+ffUVyqMxacABFutJJ72HcK7tIf2gnh2qLdKToiTkDIWT+b1RrkQPSr Gr0YapAC5PgHd/RRY75FHdW/OEQOFimouKnBc5F2VsDJg0Ae9i0+nJPWwSpoXe0ISqIUMO47 Ei6ySfHR2mjymbByxmT5W3gAT3M2gyOd/XUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB 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 MIIE7TCCA9WgAwIBAgIKKHB6MgAAAAAtBzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE1MDEyMzE3NDkyOVoXDTE2MDEyMzE3NDkyOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDF+Rcs9hNO5hvlE0YeltqeXGUW1u3RVMG4/2ag6J2FgcsOJxOZ y/m+7FeYfCo3XYrNqx6/3IZmDSYln3JnxzPionDcbK2TJ9xAOoWlrUykAhgUl+PCO8ahDV5Y c0tmMzf5MXBrsub0nUyJeDkxOUY2Id58D1UVzzXh9Kvjc+ZCcBRFoViAgn7MznnuvK8Y5m7L or1oLWSxNNUyp98gC4EpdHLnA8yP1WqmNr0x+YssjJgEiIfZFqx8Gvv2OqtHaFGHh7Y6+WOW IZULMaAc9JJEq8ctns9mGIRldf2JMFcNsahQJDhgUspmP6c1Wz9OrUxsgwnGQ5feIq9c/4YZ YEZ/AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQUR0hebk4i6063YnpEEVXyQUyfSFMwDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBDAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBADim5zjTb/h3ea/66DNM6wSm i1Ti9F2f2/Are2a7a9E/IPXfleh39lVG7uTaneEJMSHzDltkB5k6DYMv/t28ntQm2jLI9adM wccDlKSR2uIDsiA7jodiTxbqL/aRi+WC4ybWWhXuzSbkMesayt5QAKpuKLAr7newfZaWx8zP nWU1nWZBbJR7cLKgUTaEiQu/NlCWIFJIC9yRhze+KR41vIa+7niQnUANjoYCCu32Z8xgxhK4 kQr5teUVUNDoCj02x781GFfwCknxpsWEm95OWM1iaXKCGJ8ciioulEzksZUrIHdImISaQVV+ Xdmbcd3OH6y8fNl1mZdXn8sxNJc+/g0xggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCChOUsUsAAAAARPEwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQx IgQgqTS6Uyr2CCc8UNx/7JU0ytlx8SckBwF6JGOILGU1Ez4wGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUxMjE2MTgxMzU0WjANBgkqhkiG9w0BAQEFAASC AQAnjTCDmjHhvyd2/fAJTPZFfc0O6MXjtwcDBZlR5TMmBDRe0H/mOsdngssnM7UVGxrUulqM c6cBYsT97isYY4XIWhD0BNz1t5IG2+F0AQD++l/1lgCYxC4n5cq1u16YhB/r4B8v5gPiofoE /5piaoTDy1dLfEYDzJanwAxqodXM5p4wwl1qb3zAUzJFPv9Xe2/R4K+80flSvhv9J1TZrv0c 6R+6HxxveXs/dpt4q2/vuEv6+e6LS3D/AnVF31BMtqAgYjdb+Est+RN+G7/GETu2hhqdp8yZ QmbdQwluoDhqQS8hHa9sL+9ayZI+8txrUHaWLMIb63oHPNP2GHiPbvlW --B_3533116434_47352718-- From nobody Wed Dec 16 10:19:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6946A1A873B for ; Wed, 16 Dec 2015 10:19:46 -0800 (PST) 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 rlQmfqRVNvUj for ; Wed, 16 Dec 2015 10:19:44 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF981A7D81 for ; Wed, 16 Dec 2015 10:19:44 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id t125so77694647qkh.3 for ; Wed, 16 Dec 2015 10:19:44 -0800 (PST) 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=PLdlmWQrGF5B/70Ce4Y3DMdAOlnto4W0beHPGPq1XX4=; b=RmBap+0DM+V+x7iTAQgK9bzJOxYQ4Sf2wDis+NTzXdMpENvMHpvInL8/t56YjqHrBh txo0k4Rw7l7X74kQ1fWW+v7q5ptaq5p848Ylz7IGy84U+/YT08agHVAlTmaHxQwS/M1a A/AWK2MHFiylDFwX2MpgeFkYFlN2etftLauPMvh3RE6yxgKQIA/gZxwW62TESnjoUMPO RIVSXtnm0ZV9HRs+UdvNZQAvxdxTQwGCQ6ysD9+0aThjZwptiBBo2+4gVGpU0ju+dj05 Jcuk6mMMsq8tv+z7MMxeiyLdcfr08jL14zgx6ChZv223+MndGKuxNSrwIUng9MfGqGjK EZYw== MIME-Version: 1.0 X-Received: by 10.129.99.195 with SMTP id x186mr28351759ywb.345.1450289983461; Wed, 16 Dec 2015 10:19:43 -0800 (PST) Received: by 10.129.148.131 with HTTP; Wed, 16 Dec 2015 10:19:43 -0800 (PST) In-Reply-To: References: <87twnibx5p.fsf@latte.josefsson.org> Date: Wed, 16 Dec 2015 13:19:43 -0500 Message-ID: From: Watson Ladd To: "Blumenthal, Uri - 0553 - MITLL" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 18:19:46 -0000 On Wed, Dec 16, 2015 at 1:14 PM, Blumenthal, Uri - 0553 - MITLL wrote: > On 12/16/15, 12:16 , "Watson Ladd" wrote: > >>On Wed, Dec 16, 2015 at 12:09 PM, Blumenthal, Uri - 0553 - MITLL >> wrote: >>> On 12/16/15, 10:50, "Watson Ladd" wrote: >>>>>If there are practical consequences, like loss of confidentiality =E2= =80=93 I=E2=80=99m >>>>> dying to hear the outline of a practical attack. >>>> >>>>The problem is that people design systems assuming something like >>>>indistinguishability. And so when you violate that assumption, all >>>>bets are off. >>> >>> I don=E2=80=99t buy this. AFAIK, TLS has not been designed based on tha= t >>> assumption. And I=E2=80=99m not making any bets. :) >> >>What security properties does TLS provide? > > When the vast majority of TLS users employ it (TLS), they expect (a) that > TLS would ensure the authenticity of their remote peer, (b) that TLS woul= d > protect their data exchange from being eavesdropped on and/or modified, > and (c) that these hold even when the =E2=80=9Cenemy=E2=80=9D (whoever he= might be) > controls the entire communications path between them and their peers. > > You can translate the above into more formal definition. :-) > >>In the past TLS users have made assumptions that TLS provides security >>properties it does not. > > Very true. > >>The solution to this problem is to provide the security properties >>that people expect, and they expect IND. > > Not necessarily so. > > As far as I=E2=80=99m concerned, IND-* is a good property to have, but no= t a > =E2=80=9Csacred cow=E2=80=9D. Do you have an alternative definition you can put in and crank and get the limit out? That's the level of definition at which this sort of analysis has to be done, not blathering about "confidentiality" and specific attacks. The reason I used IND-* is that's what the analyses that have been performed used, because it is defined well enough to do this. From nobody Wed Dec 16 11:57:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C1B1A8954 for ; Wed, 16 Dec 2015 11:57:46 -0800 (PST) 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, 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 XlCqQswtpjoE for ; Wed, 16 Dec 2015 11:57:44 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799541A8949 for ; Wed, 16 Dec 2015 11:57:44 -0800 (PST) Received: by mail-ob0-x233.google.com with SMTP id sd4so41478542obb.0 for ; Wed, 16 Dec 2015 11:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9q7Les3w066ZMx0FowUAr68//RD7uCWbGUL3oCYOT/0=; b=FBQHSI4I8QiN5++EsIn1LQpTbGpVkmuEnSwb1OzHn91i5bczXejg/HP+HWG++iHNOT q4fXVmF/iCKDQjC3jqCSn8LnuNET83BFpqXXtLtB06Bc4jfStz88TNVgy2l07eLeuOFt EPoQ6PE99SQd0l6as8YcF/KrTdkobw8qWDd5h9cf7dX523tSt2+c1HNSIUv7x06PmOTq dPWzY4HKsnVBYg9lxlHaDiqBFMLpRF4wadsJ0qSuJ19oVKHf80XOJuPDmWU57urZCpnt t/aPySuhrCpVeNC+M0QAuBaHwXT4bG966MiAkCPuxtMEg3V456Uwy5dd4I4HvzpGjH/p AfmQ== 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=9q7Les3w066ZMx0FowUAr68//RD7uCWbGUL3oCYOT/0=; b=RicoZZDWdLrR/m6ncaHduiMFLS6IWPSJkDgzqQLMdtlruinSCI6h6BzVNClp/GwJ8U YsGTBBO5xdcaDBV974OcO2KvbY0yDTWX7St1eu29W3ifz2wfOPAZ+GExutmpK58Hf3LC JXi2qgXbUYtj5BnDfK5Hve+ru7DkJ+4yplY2AfYMh5Sww4apSlErhFeV9XqNEieNDcD2 BiHSrFToXow+QgsZfspRlpSZpSJeyVtw2B8rQGoyXEVG7kktZuaGJ1wvTYR9Y16S44YX tEx/VoVBT+qaVllY8A7LX02QtXAxG29NmvwmYKonLFLqeD/hmLqkbCKGiadItkIlHQm5 7T3Q== X-Gm-Message-State: ALoCoQny2Xw48Z7YrHUljMopXVOecoGCBS2N2yA30WSiWQVmkJi3EqrKwlVVls1wWOw+yqd+QgroPaCbaG5qz+9EKI5cfXoJzQ== MIME-Version: 1.0 X-Received: by 10.182.16.233 with SMTP id j9mr32305862obd.9.1450295863909; Wed, 16 Dec 2015 11:57:43 -0800 (PST) Received: by 10.76.82.41 with HTTP; Wed, 16 Dec 2015 11:57:43 -0800 (PST) In-Reply-To: References: <87twnibx5p.fsf@latte.josefsson.org> Date: Wed, 16 Dec 2015 09:57:43 -1000 Message-ID: From: Brian Smith To: Eric Rescorla , Watson Ladd Content-Type: multipart/alternative; boundary=001a11c30aa2c9b46c052709512e Archived-At: Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 19:57:46 -0000 --001a11c30aa2c9b46c052709512e Content-Type: text/plain; charset=UTF-8 Eric Rescorla wrote: > > I believe Watson provided one a while back at: > https://www.ietf.org/mail-archive/web/tls/current/msg18240.html > So, if [2] is correct, then we can take Watson's 2^36 and multiply it by 2^17 to get 2^53 bytes as the limit? It seems so, since [2] claims that they've improved the bounds by 2^17. Note that 3 out of 4 of the authors of [2] are the same authors as [1], which is the paper that defined the formula that the 2^36 number was calculated from. Earlier (in another thread), we agreed that an implementation would not send 2^48 or more records. A limit of 2^53 bytes would allow for 2^39 maximally-sized (16KB) records, which is not far off from the 2^48 theoretical maximum that the record sequence number allows. More importantly, 2^53 == 10^15 == 1 petabyte == 1,000,000 gigabytes; I think we can live with an upper limit of byte sent that is even much smaller than that. [1] https://eprint.iacr.org/2012/438.pdf [2] https://eprint.iacr.org/2015/214.pdf Therefore, I think we shouldn't add the rekeying mechanism as it is unnecessary and it adds too much complexity. Also, the above limits apply to AES-GCM but not ChaCha20-Poly1305. So, at the very least, we should avoid the rekeying complexity for ChaCha20-Poly1305 and other AEADs that don't need it. And, implementations that don't intend to send these giant quantities of data, even with AES-GCM, shouldn't be required, implicitly or explicitly, to implement the rekeying. Cheers, Brian -- https://briansmith.org/ --001a11c30aa2c9b46c052709512e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Eric= Rescorla <ekr@rtfm.com> wrote:
=

I believe Watson provided one a while back at:

So, if [2] is correct, then we can take Watson's 2^36 and multiply it= by 2^17 to get 2^53 bytes as the limit? It seems so, since [2] claims that= they've improved the bounds by 2^17. Note that 3 out of 4 of the autho= rs of [2] are the same authors as [1], which is the paper that defined the = formula that the 2^36 number was calculated from.

= Earlier (in another thread), we agreed that an implementation would not sen= d 2^48 or more records. A limit of 2^53 bytes would allow for 2^39 maximall= y-sized (16KB) records, which is not far off from the 2^48 theoretical maxi= mum that the record sequence number allows. More importantly, 2^53 =3D=3D 1= 0^15 =3D=3D 1 petabyte =3D=3D 1,000,000 gigabytes; I think we can live with= an upper limit of byte sent that is even much smaller than that.

<= div>
Therefore, I think we shouldn't add the rekeying mec= hanism as it is unnecessary and it adds too much complexity. Also, the abov= e limits apply to AES-GCM but not ChaCha20-Poly1305. So, at the very least,= we should avoid the rekeying complexity for ChaCha20-Poly1305 and other AE= ADs that don't need it. And, implementations that don't intend to s= end these giant quantities of data, even with AES-GCM, shouldn't be req= uired, implicitly or explicitly, to implement the rekeying.

<= /div>
Cheers,
Brian
--
<= a href=3D"https://briansmith.org/" target=3D"_blank">https://briansmith.org= /

--001a11c30aa2c9b46c052709512e-- From nobody Wed Dec 16 12:01:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8F41A89FA for ; Wed, 16 Dec 2015 12:01:50 -0800 (PST) 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 DubIXmyovcc7 for ; Wed, 16 Dec 2015 12:01:47 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C660A1A8967 for ; Wed, 16 Dec 2015 12:00:54 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id k189so82743121qkc.0 for ; Wed, 16 Dec 2015 12:00:54 -0800 (PST) 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=vP4KyvmQ0FYeUkaYu/L9F0uKR4Uv2vkTjsle4PEy97U=; b=NuW5HeS08xdtmZhvYQMpnvjSJ+44vvkimkwDXucu2zSX2UFAtC//DPvr7zkRZqIayI 1FDVdWyceWyYZLRwZuKlfYBR5QdNNnHiNfhUasCkIgcvsTlFwBsexAujeC7TJMGzPoEK deE51lrCC+jSxjrN+VYqzjkPN1lj6wQQlAVYBQ9ToPtGVI3fB0oLfhcqvF/u0XBO9UWv YcBvKR7VDunpYZOPMCsfE0df59RIlb74cCVtN1nrnJxuTaSBkYcp5m/GQ3oVEjA3yb5T rQ12yNk2VJkL/onSkLeXnCnkQlY/C6M5pXyhQNqaURSGV4YoLif6F5JqxqTnpjD8fkWZ AtBQ== MIME-Version: 1.0 X-Received: by 10.129.57.135 with SMTP id g129mr27868412ywa.244.1450296053967; Wed, 16 Dec 2015 12:00:53 -0800 (PST) Received: by 10.129.148.131 with HTTP; Wed, 16 Dec 2015 12:00:53 -0800 (PST) In-Reply-To: References: <87twnibx5p.fsf@latte.josefsson.org> Date: Wed, 16 Dec 2015 15:00:53 -0500 Message-ID: From: Watson Ladd To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 20:01:51 -0000 On Wed, Dec 16, 2015 at 2:57 PM, Brian Smith wrote: > Eric Rescorla wrote: >> >> >> I believe Watson provided one a while back at: >> https://www.ietf.org/mail-archive/web/tls/current/msg18240.html > > > So, if [2] is correct, then we can take Watson's 2^36 and multiply it by > 2^17 to get 2^53 bytes as the limit? It seems so, since [2] claims that > they've improved the bounds by 2^17. Note that 3 out of 4 of the authors of > [2] are the same authors as [1], which is the paper that defined the formula > that the 2^36 number was calculated from. You need to actually read the papers and understand which formulas are modified. If you did you would see the improvement is in AES-GCM with funny nonce sizes, not the confidentiality issue. > > Earlier (in another thread), we agreed that an implementation would not send > 2^48 or more records. A limit of 2^53 bytes would allow for 2^39 > maximally-sized (16KB) records, which is not far off from the 2^48 > theoretical maximum that the record sequence number allows. More > importantly, 2^53 == 10^15 == 1 petabyte == 1,000,000 gigabytes; I think we > can live with an upper limit of byte sent that is even much smaller than > that. > > [1] https://eprint.iacr.org/2012/438.pdf > [2] https://eprint.iacr.org/2015/214.pdf > > Therefore, I think we shouldn't add the rekeying mechanism as it is > unnecessary and it adds too much complexity. Also, the above limits apply to > AES-GCM but not ChaCha20-Poly1305. So, at the very least, we should avoid > the rekeying complexity for ChaCha20-Poly1305 and other AEADs that don't > need it. And, implementations that don't intend to send these giant > quantities of data, even with AES-GCM, shouldn't be required, implicitly or > explicitly, to implement the rekeying. > > Cheers, > Brian > -- > https://briansmith.org/ > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Dec 16 12:30:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398A71A89B0 for ; Wed, 16 Dec 2015 12:30:11 -0800 (PST) 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 cRk0gd-96SRx for ; Wed, 16 Dec 2015 12:30:09 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510F91A88DF for ; Wed, 16 Dec 2015 12:30:09 -0800 (PST) Received: by mail-qg0-x22c.google.com with SMTP id 21so44559245qgx.1 for ; Wed, 16 Dec 2015 12:30:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=lAENXlh0/ryfiGotb5vhZoEdSOXKLd6aiYqDwPzzv6c=; b=Z+In5Zv3sV6Org1zfLH9fErT8MyYozgZ0RmCmRm1jNb7QiPhXQIT8i4kggvjuC0ezg d7kwTOSxuE34Wnhwt3phtPvE2ooF3xn17WBM+6SuldFzFf0g9om5wRtnkLhqhXfb7V5Z cihJXIihshsUL+1NIBNc2yakfT3CHjTXt2CJ5IIYEsZUmFbmwlaFAnmDiJVgOdNSJ5e1 aqSoYeCaXxyNszxyfHcbwsHQNctBbuFIPfoVkL9dO7AMdENEY044UJX+V23twQpj8+VR NMdq1IfDyVJ0ag3PUFhohF68SNBtzcYKQE+5KGQ/I7saB6oXAiwP9giLZOf/rsS55dy+ lPow== X-Received: by 10.140.220.136 with SMTP id q130mr56131147qhb.24.1450297808562; Wed, 16 Dec 2015 12:30:08 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id z65sm3232924qhb.22.2015.12.16.12.30.07 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 16 Dec 2015 12:30:07 -0800 (PST) From: Dave Garrett To: John Foley Date: Wed, 16 Dec 2015 15:30:05 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <56718D7A.4000302@cisco.com> In-Reply-To: <56718D7A.4000302@cisco.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201512161530.06122.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Explicit use of client and server random values X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2015 20:30:11 -0000 On Wednesday, December 16, 2015 11:12:42 am John Foley wrote: > I apologize if this topic was previously discussed, I've only recently > joined the TLS mailer list. While reviewing the TLS 1.3 draft (revision > 10), section 7 begins with the following wording: > > In order to begin connection protection, the TLS Record Protocol > requires specification of a suite of algorithms, a master secret, and > the client and server random values. > > However, when reading through all of section 7, there appears to be no > explicit use for the client and server random values. While these > values would be used implicitly when the handshake messages are hashed, > and thus have bearing on the key schedule calculation, there appears to > be no explicit use of the client and server random values similar to > section 6.3 in the TLS 1.2 spec. > > Am I interpreting this properly? Yes, with the exception of the new downgrade protection mechanism that rides in the server random (in draft11 WIP), randoms are used implicitly via the handshake hash. > If the client and server random values > are no longer explicitly used in any key derivation logic, maybe this > should be noted in section 6.3.1, as implementors will no longer need to > parse these values when processing incoming messages. Additionally, the > intro to section 7 is misleading to implementors, as it implies the > client and server random values are needed to derive the key schedule. There's still a lot of stuff with "TODO" notes on it in there that needs revision with regard to this. In particular, SecurityParameters still contains the randoms as well as the old master secret. I agree that this needs explicit explanation. > The following issue and PR appear to be related to my question: > > https://github.com/tlswg/tls13-spec/issues/185 > https://github.com/tlswg/tls13-spec/pull/189 Not really. The issue there was a suggestion to regen the randoms on retry request. Yes, it touches the randoms, but it's a tangential issue. In any case, the idea in question has been shelved. Dave PS When referencing sections in the draft, please do so not just by number. Those can change as sections change. I suggest linking to one of the numbered drafts and citing its section, where possible. 6.3.1 is already different between draft10 and the current draft11 WIP. From nobody Wed Dec 16 13:14:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A1D1A8A79 for ; Wed, 16 Dec 2015 13:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, 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 hkQULs30qUWT for ; Wed, 16 Dec 2015 13:14:31 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3E731A8A6D for ; Wed, 16 Dec 2015 13:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2858; q=dns/txt; s=iport; t=1450300470; x=1451510070; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Vl4hb4qfy1V+NeeidHbMLMLHZPiDxlqNPEv6Ii3d5ik=; b=AeIHGvTOSUwMnixADOfdpD88vJTCXzMHkZyGEeBsyBXuWBsk43Kp78U0 mtazpnMbJXttHU/Jw+T6dOIDCJ++uIqc7z05wpr8gWvjXgJICPenTNIw9 /PitBSzaGtttEpl9py8UDQ3vBv8MbjUpnxpuDjBLCEHW1rIxxpn65Dwds g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSAgBs03FW/4QNJK1egzpSvmUBDYFjI?= =?us-ascii?q?YVsAoEtOBQBAQEBAQEBgQqENQEBBDhAARALGAkWDwkDAgECAUUGDQgBAYgrDr4?= =?us-ascii?q?dAQEBAQEBAQEBAQEBAQEBAQEBARYEi1OCcYFRhH4FjiyIUIU5gnGFHoFchEWDB?= =?us-ascii?q?ZN1HwEBQoIQHoF0hWYBAQE?= X-IronPort-AV: E=Sophos;i="5.20,438,1444694400"; d="scan'208";a="56193133" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Dec 2015 21:14:30 +0000 Received: from [64.102.56.172] (dhcp-64-102-56-172.cisco.com [64.102.56.172]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tBGLETb2006150; Wed, 16 Dec 2015 21:14:29 GMT To: Dave Garrett References: <56718D7A.4000302@cisco.com> <201512161530.06122.davemgarrett@gmail.com> From: John Foley Message-ID: <5671D454.6000506@cisco.com> Date: Wed, 16 Dec 2015 16:15:00 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <201512161530.06122.davemgarrett@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Explicit use of client and server random values X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2015 21:14:32 -0000 On 12/16/2015 03:30 PM, Dave Garrett wrote: > On Wednesday, December 16, 2015 11:12:42 am John Foley wrote: >> I apologize if this topic was previously discussed, I've only recently >> joined the TLS mailer list. While reviewing the TLS 1.3 draft (revision >> 10), section 7 begins with the following wording: >> >> In order to begin connection protection, the TLS Record Protocol >> requires specification of a suite of algorithms, a master secret, and >> the client and server random values. >> >> However, when reading through all of section 7, there appears to be no >> explicit use for the client and server random values. While these >> values would be used implicitly when the handshake messages are hashed, >> and thus have bearing on the key schedule calculation, there appears to >> be no explicit use of the client and server random values similar to >> section 6.3 in the TLS 1.2 spec. >> >> Am I interpreting this properly? > Yes, with the exception of the new downgrade protection mechanism that rides in the server random (in draft11 WIP), randoms are used implicitly via the handshake hash. > >> If the client and server random values >> are no longer explicitly used in any key derivation logic, maybe this >> should be noted in section 6.3.1, as implementors will no longer need to >> parse these values when processing incoming messages. Additionally, the >> intro to section 7 is misleading to implementors, as it implies the >> client and server random values are needed to derive the key schedule. > There's still a lot of stuff with "TODO" notes on it in there that needs revision with regard to this. In particular, SecurityParameters still contains the randoms as well as the old master secret. I agree that this needs explicit explanation. > >> The following issue and PR appear to be related to my question: >> >> https://github.com/tlswg/tls13-spec/issues/185 >> https://github.com/tlswg/tls13-spec/pull/189 > Not really. The issue there was a suggestion to regen the randoms on retry request. Yes, it touches the randoms, but it's a tangential issue. In any case, the idea in question has been shelved. > > > Dave > > > PS > When referencing sections in the draft, please do so not just by number. Those can change as sections change. I suggest linking to one of the numbered drafts and citing its section, where possible. 6.3.1 is already different between draft10 and the current draft11 WIP. > . > Thanks for answering my questions. Have you considered adding KAT values for the key derivation steps? This would be helpful to implementors. RFC5869 already has KAT values for HKDF-Extract and HKDF-Expand. But the TLS 1.3 spec has added HKDF-Expland-Label. Additionally, It would be useful to show intermediate KAT values for xSS, xES, mSS, and mES. From nobody Wed Dec 16 13:28:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9B31A8AB8 for ; Wed, 16 Dec 2015 13:28:06 -0800 (PST) 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 P6wyEZYlSFEz for ; Wed, 16 Dec 2015 13:28:05 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C8EF1A89EB for ; Wed, 16 Dec 2015 13:28:05 -0800 (PST) Received: by mail-qg0-x231.google.com with SMTP id 103so45892331qgi.3 for ; Wed, 16 Dec 2015 13:28:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=7vuhnB/V2wwojV/p20fKmG6abKLBwE7OcJCS6jym0uM=; b=thzTveX7ldNQcHbS0rM1A12oYZqRQzxOqb5PcCpzrcQzVuDEohZcnt7pkEuwcYVRcz q8n2NpqJuCleNw0TzVjGsq5aPJscoH+bkTPq2eVhjvRB/X5W7HICcu8m++AGuCfItQYK Dz4dNVvWLxVN/LwSbrkJvY3C4ShKY/eAuXU8c7yWXKWreewk1JKiryO+zedhUPWTN1VP C8TfYRyhi7DJquR3Whvw2FW6jk4WmPBm62tvQI6vp2btG2TOZNJJz1r3v2JzqvgVXnqC P7YIBkgw3WnmlOvAkmIOVuAgIuaZKC/MEaEv2IEYWNexc05rC78dK1iQLJAQpvGla+mH c1XA== X-Received: by 10.140.31.197 with SMTP id f63mr6769439qgf.12.1450301284656; Wed, 16 Dec 2015 13:28:04 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id w32sm3350390qgw.6.2015.12.16.13.28.03 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 16 Dec 2015 13:28:03 -0800 (PST) From: Dave Garrett To: John Foley Date: Wed, 16 Dec 2015 16:28:02 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <56718D7A.4000302@cisco.com> <201512161530.06122.davemgarrett@gmail.com> <5671D454.6000506@cisco.com> In-Reply-To: <5671D454.6000506@cisco.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <201512161628.02986.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Explicit use of client and server random values X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Dec 2015 21:28:06 -0000 On Wednesday, December 16, 2015 04:15:00 pm John Foley wrote: > Thanks for answering my questions. Have you considered adding KAT > values for the key derivation steps? This would be helpful to > implementors. RFC5869 already has KAT values for HKDF-Extract and > HKDF-Expand. But the TLS 1.3 spec has added HKDF-Expland-Label. > Additionally, It would be useful to show intermediate KAT values for > xSS, xES, mSS, and mES. I suggest filing an issue or submitting a PR with a starting point set of changes and discussing it with ekr. Dave From nobody Wed Dec 16 14:26:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280EF1A9022 for ; Wed, 16 Dec 2015 14:26:21 -0800 (PST) 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, 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 fK-n8Myeky5j for ; Wed, 16 Dec 2015 14:26:19 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A141A900A for ; Wed, 16 Dec 2015 14:26:18 -0800 (PST) Received: by mail-ob0-x232.google.com with SMTP id iw8so43650513obc.1 for ; Wed, 16 Dec 2015 14:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jn23w2DRkZIWt/tXtyeBlpaw4xWj0ZYhYQt8Grdmgj8=; b=HbRaXFZSx2uzzCFMNnrAYgv/K2k3YooZxVn6I+2bl5uU8waT0qqM/iu3J3GBUXbHlN RmqLOOS4lYkfBDhf0TqJJhoKakU7T77LtMs2IyftHP/zuu8Ne2Ui8F6BkPDuJkMbHBhP k+ZWJITDKlsM280IfHI2IN6AFjhQ5WQl5BEZ3tEXCOveO6gORAoJFw1BbdnXRZnTV69y u4I1Ck2by2kJwM0SuHMZwBmnsnT/rbAvDegeo7ySm8MrxOylRt1BOU1vyyIFamba9VIj TUudRSnQ48t1E4Hxef8JXNtSHY6ddQPgCa4wRqeCk3F+2UE5qKBbl71vUiXPoWCVkgqZ zghQ== 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=jn23w2DRkZIWt/tXtyeBlpaw4xWj0ZYhYQt8Grdmgj8=; b=GpuOgL/uJdZqftwSI+8L4DtBlA7+jfkdCQBbBY/XP7vsP8hMQt9x71bWO4IcCiRuTO 6/4nDbtygTXQA8zzvLooccFfnTBgNzw4axlkMm29Hb7UcDGAdMVgsdMBYZoD7WoN+SkE wkMzFA6R2cOvUWXIV1YIjxJTB36Dv/L7DZvOVrPObupNjrHezCpRB1w/IH0k6aVoAjev 2lrhVopKg8JPO/Qk531N+B/S3qn1rV9tyDOkN+vOU2guCUwiwPik9ka9OA+Zvp02aBTQ g5f69NakU5cZ1ASIE1LCd+MZLRDKeRS6X5s6YAJbZCYR+YI0/KIbQyQV/bbyiep6suoX XJmw== X-Gm-Message-State: ALoCoQlSZvZH2db9d5VXhS2aWBHQT+BCXM5kxYIMRmIwbA7SagDX+CQbm7A1VZrebTXPBuTCEkrBuGE0HSVkmF7ykT8DrkywEA== MIME-Version: 1.0 X-Received: by 10.60.98.33 with SMTP id ef1mr34058306oeb.62.1450304778263; Wed, 16 Dec 2015 14:26:18 -0800 (PST) Received: by 10.76.82.41 with HTTP; Wed, 16 Dec 2015 14:26:17 -0800 (PST) In-Reply-To: References: <87twnibx5p.fsf@latte.josefsson.org> Date: Wed, 16 Dec 2015 12:26:17 -1000 Message-ID: From: Brian Smith To: Watson Ladd Content-Type: multipart/alternative; boundary=089e0115edca1ff96105270b65b6 Archived-At: Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 22:26:21 -0000 --089e0115edca1ff96105270b65b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Watson Ladd wrote: > Brian Smith wrote: > > So, if [2] is correct, then we can take Watson's 2^36 and multiply it b= y > > 2^17 to get 2^53 bytes as the limit? It seems so, since [2] claims that > > they've improved the bounds by 2^17. Note that 3 out of 4 of the author= s > of > > [2] are the same authors as [1], which is the paper that defined the > formula > > that the 2^36 number was calculated from. > > You need to actually read the papers and understand which formulas are > modified. If you did you would see the improvement is in AES-GCM with > funny nonce sizes, not the confidentiality issue. > Great. Thank you for pointing out my mistake. First, I'll correct my mistake in understanding [2]. Then, I'll verify your derivation how we can get the "2^36 bytes" figure. Lastly, I'll ask whether the initial premise under which we derived that number is meaningful. In particular, many people seem to be using a limit of 2^-18 for the attackers distinguishability advantage to allow (over) 2^48 bytes to be sent, but the 2^36 limit we derived comes from using the number 2^-60 instead. But, is 2^-60 really the right number to use? It seems like we can likely tolerate a much higher probability of distinguishability. However, it isn't clear what probability of distinguishability is sufficient. In other words, there is a tension between the strictness in demanding proof of IND-* security vs. the simplicity of the protocol (rekeying or now) for AES-GCM. I believe it is worth asking more cryptographers for help in determining this limit. First, my mistake in understanding [2]: The improvements to [2] are for Theorem 1 in [1], which is about AES-GCM in general, for all nonce lengths. However, [1] also defined Corollary 3 that tightens the bound for the case where the nonce length is 96 bits, which completely avoids the term with factor 2^22. So, the 2^17 improvement in [2] for Theorem 1 is not relevant because we're using Corollary 3, which is already even tighter. Sorry for wasting people's time with that. Second, let's go back to how we got 2^36. We used Corollary 3 from [1], which has this formula: 0.5(=CF=83 + q + 1)^2 / 2^n We rename =CF=83 to s: 0.5(s + q + 1)^2 / 2^n substitute n =3D=3D 128: 0.5(s + q + 1)^2 / 2^128 and simplify: (s + q + 1)^2 / 2^127 we get the formula in Watson's email [3]. In that email, Watson then claimed that we want to keep this quantity under 2^-60: (s + q + 1)^2 / 2^127 < 2^-60. Simplified: (s + q + 1)^2 < 2^67. Further simplified: s + q + 1 < 2^33.5. So, Watson's point in [3], as I understand it, is that even if we ignore q, s must be less than 2^32. 2^32 blocks * 2^4 bytes per block =3D 2^36 bytes = in order to have a proof of IND-* security for AES-GCM, So we'd need to send 2^36 or fewer bytes to have proven IND-* security. Lastly, let's reconsider Watson's claim in [3] that 1/2^60 is the correct bound. In [0], the authors wrote: "To provide a concrete example, these results show that, if AES is indistinguishable from a random permutation, and fewer than 2^48 packets are protected, then the attacker=E2=80=99s adva= ntage is no more than 2^=E2=88=9218." This implies that David thought that 2^-18 was= a sufficient bound. Note that even the conclusion of [1] says that its bounds for the 96-bit nonce case is tighter than the bounds from the original proof [0]. So, it seems strange to use [1] to refute the above claim from [0], when in fact [1] strengthens [0] for the case of 96-nonces, which is what TLS uses. [0] https://eprint.iacr.org/2004/193.pdf > [1] https://eprint.iacr.org/2012/438.pdf > > [2] https://eprint.iacr.org/2015/214.pdf [3] https://www.ietf.org/mail-archive/web/tls/current/msg18240.html Cheers, Brian --=20 https://briansmith.org/ --089e0115edca1ff96105270b65b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wats= on Ladd <watsonbladd@gmail.com> wrote:
Brian Smith <brian@briansmith.org> wrote:
> So, if [2] is correct, = then we can take Watson's 2^36 and multiply it by
> 2^17 to get 2^53 bytes as the limit? It seems so, since [2] claims tha= t
> they've improved the bounds by 2^17. Note that 3 out of 4 of the a= uthors of
> [2] are the same authors as [1], which is the paper that defined the f= ormula
> that the 2^36 number was calculated from.

You need to actually read the papers and understand which formulas a= re
modified. If you did you would see the improvement is in AES-GCM with
funny nonce sizes, not the confidentiality issue.

=
Great. Thank you for pointing out my mistake. First, I'll co= rrect my mistake in understanding [2]. Then, I'll verify your derivatio= n how we can get the "2^36 bytes" figure. Lastly, I'll ask wh= ether the initial premise under which we derived that number is meaningful.= In particular, many people seem to be using a limit of 2^-18 for the attac= kers distinguishability advantage to allow (over) 2^48 bytes to be sent, bu= t the 2^36 limit we derived comes from using the number 2^-60 instead. But,= is 2^-60 really the right number to use? It seems like we can likely toler= ate a much higher probability of distinguishability. However, it isn't = clear what probability of distinguishability is sufficient. In other words,= there is a tension between the strictness in demanding proof of IND-* secu= rity vs. the simplicity of the protocol (rekeying or now) for AES-GCM. I be= lieve it is worth asking more cryptographers for help in determining this l= imit.

First, my mistake in understanding [2]: The = improvements to [2] are for Theorem 1 in [1], which is about AES-GCM in gen= eral, for all nonce lengths. However, [1] also defined Corollary 3 that tig= htens the bound for the case where the nonce length is 96 bits, which compl= etely avoids the term with factor 2^22. So, the 2^17 improvement in [2] for= Theorem 1 is not relevant because we're using Corollary 3, which is al= ready even tighter. Sorry for wasting people's time with that.

Second, let's go back to how we got 2^36. We used Coro= llary 3 from [1], which has this formula:

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 0.5(=CF=83 + q + 1)^2 / 2^n

W= e rename =CF=83 to s:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = 0.5(s + q + 1)^2 / 2^n

substitute n =3D= =3D 128:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 0.5(s + = q + 1)^2 / 2^128

and simplify:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (s + q + 1)^2 / 2^12= 7
=C2=A0 =C2=A0
we get the formula in Wat= son's email [3]. In that email, Watson then claimed that we want to kee= p this quantity under 2^-60:

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 (s + q + 1)^2 / 2^127 < 2^-60.

Simpl= ified:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (s + q + 1)^2 &= lt; 2^67.

Further simplified:
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 s + q + 1 < 2^33.5.
<= /div>
=C2=A0
So, Watson's point in [3], as I understand i= t, is that even if we ignore q, s must be less than 2^32. 2^32 blocks * 2^4= bytes per block =3D 2^36 bytes in order to have a proof of=C2=A0IND-* secu= rity for AES-GCM, So we'd need to send 2^36 or fewer bytes to have prov= en IND-* security.

Lastly, let's reconsider Wa= tson's claim in [3] that=C2=A01/2^60 is the correct bound. In [0], the = authors wrote: "To provide a concrete example, these results show that, if AES is indistinguis= hable from a random permutation, and fewer than 2^48 packets are protected, then = the attacker=E2=80=99s advantage is no more than 2^=E2=88=9218." This impl= ies that David thought that 2^-18 was a sufficient bound.

Note that even the conclusion of [1] says that its bounds for the 9= 6-bit nonce case is tighter than the bounds from the original proof [0]. So= , it seems strange to use [1] to refute the above claim from [0], when in f= act [1] strengthens [0] for the case of 96-nonces, which is what TLS uses.<= /div>


> [1] https://eprint.iacr.org/2012/438.p= df
> [2] https://eprint.iacr.org/2015/214.pdf

[3]=C2=A0https://www.ietf.org/mail-archive/web/tls/curre= nt/msg18240.html

Cheers,
Brian
--
--089e0115edca1ff96105270b65b6-- From nobody Wed Dec 16 14:28:53 2015 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCA01A9028; Wed, 16 Dec 2015 14:28:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151216222851.29133.20035.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 14:28:51 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-04.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: Wed, 16 Dec 2015 22:28:51 -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 : ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) Authors : Adam Langley Wan-Teh Chang Nikos Mavrogiannopoulos Joachim Strombergson Simon Josefsson Filename : draft-ietf-tls-chacha20-poly1305-04.txt Pages : 7 Date : 2015-12-16 Abstract: This document describes the use of the ChaCha stream cipher and Poly1305 authenticator in the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-chacha20-poly1305-04 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 Wed Dec 16 14:33:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1DE1A903D for ; Wed, 16 Dec 2015 14:33:32 -0800 (PST) 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 vQADJmt5ZpMV for ; Wed, 16 Dec 2015 14:33:29 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FF351A9041 for ; Wed, 16 Dec 2015 14:33:29 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id u65so69974821qkh.2 for ; Wed, 16 Dec 2015 14:33:29 -0800 (PST) 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=YEyKDquoKsSiCbYTjg6DDMk0KjBe04yughaVPb8XjpA=; b=yLTDmWm1yQaETPp0igYvwd1lrwTdFvC2eSYjhQL4OueQjdPPx4XfSE+QWTBVaeXTD5 TJuvRC1Pp70t8NjFW7sdEEHer/PVt++qOI/wt2EC8K2qsuslOISFuZvp/27HDgCayfWp 4QvGhmJN5Hsse3p9ElJZBCaqVQQswQhLq5Nt4ZFB5vmvNilPbfs/sD6tBjjio/TJ0Qgg nDlIX2zaiL9n9YXn7jOs73naQZYi2pUHjRdy8lxr/6bdExhusdeMWDtzMx0yA5Y6TYCA zXZBPNG9YeKWGvfr/7kDDKHrxr2top3J0TiqkxD7BKO564sLRWigQnGsRS+5OIkMPC55 ErMw== MIME-Version: 1.0 X-Received: by 10.129.99.195 with SMTP id x186mr29275162ywb.345.1450305208525; Wed, 16 Dec 2015 14:33:28 -0800 (PST) Received: by 10.129.148.131 with HTTP; Wed, 16 Dec 2015 14:33:28 -0800 (PST) Received: by 10.129.148.131 with HTTP; Wed, 16 Dec 2015 14:33:28 -0800 (PST) In-Reply-To: References: <87twnibx5p.fsf@latte.josefsson.org> Date: Wed, 16 Dec 2015 17:33:28 -0500 Message-ID: From: Watson Ladd To: Brian Smith Content-Type: multipart/alternative; boundary=001a114920f8c52eb805270b7e6d Archived-At: Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] Data volume 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: Wed, 16 Dec 2015 22:33:32 -0000 --001a114920f8c52eb805270b7e6d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Dec 16, 2015 5:26 PM, "Brian Smith" wrote: > > Watson Ladd wrote: > >> Brian Smith wrote: >> > So, if [2] is correct, then we can take Watson's 2^36 and multiply it by >> > 2^17 to get 2^53 bytes as the limit? It seems so, since [2] claims tha= t >> > they've improved the bounds by 2^17. Note that 3 out of 4 of the authors of >> > [2] are the same authors as [1], which is the paper that defined the formula >> > that the 2^36 number was calculated from. >> >> You need to actually read the papers and understand which formulas are >> modified. If you did you would see the improvement is in AES-GCM with >> funny nonce sizes, not the confidentiality issue. > > > Great. Thank you for pointing out my mistake. First, I'll correct my mistake in understanding [2]. Then, I'll verify your derivation how we can get the "2^36 bytes" figure. Lastly, I'll ask whether the initial premise under which we derived that number is meaningful. In particular, many people seem to be using a limit of 2^-18 for the attackers distinguishability advantage to allow (over) 2^48 bytes to be sent, but the 2^36 limit we derived comes from using the number 2^-60 instead. But, is 2^-60 really the right number to use? It seems like we can likely tolerate a much higher probability of distinguishability. However, it isn't clear what probability of distinguishability is sufficient. In other words, there is a tension between the strictness in demanding proof of IND-* security vs. the simplicity of the protocol (rekeying or now) for AES-GCM. I believe it is worth asking more cryptographers for help in determining this limit. We've already decided to add a far more complicated support for new authentication. Reykeyinh is not that complicated. > > First, my mistake in understanding [2]: The improvements to [2] are for Theorem 1 in [1], which is about AES-GCM in general, for all nonce lengths. However, [1] also defined Corollary 3 that tightens the bound for the case where the nonce length is 96 bits, which completely avoids the term with factor 2^22. So, the 2^17 improvement in [2] for Theorem 1 is not relevant because we're using Corollary 3, which is already even tighter. Sorry for wasting people's time with that. > > Second, let's go back to how we got 2^36. We used Corollary 3 from [1], which has this formula: > > 0.5(=CF=83 + q + 1)^2 / 2^n > > We rename =CF=83 to s: > > 0.5(s + q + 1)^2 / 2^n > > substitute n =3D=3D 128: > > 0.5(s + q + 1)^2 / 2^128 > > and simplify: > > (s + q + 1)^2 / 2^127 > > we get the formula in Watson's email [3]. In that email, Watson then claimed that we want to keep this quantity under 2^-60: > > (s + q + 1)^2 / 2^127 < 2^-60. > > Simplified: > > (s + q + 1)^2 < 2^67. > > Further simplified: > > s + q + 1 < 2^33.5. > > So, Watson's point in [3], as I understand it, is that even if we ignore q, s must be less than 2^32. 2^32 blocks * 2^4 bytes per block =3D 2^36 byt= es in order to have a proof of IND-* security for AES-GCM, So we'd need to send 2^36 or fewer bytes to have proven IND-* security. > > Lastly, let's reconsider Watson's claim in [3] that 1/2^60 is the correct bound. In [0], the authors wrote: "To provide a concrete example, these results show that, if AES is indistinguishable from a random permutation, and fewer than 2^48 packets are protected, then the attacker=E2=80=99s adva= ntage is no more than 2^=E2=88=9218." This implies that David thought that 2^-18 was= a sufficient bound. There are likely to be over 2^40 tls connections globally. > > Note that even the conclusion of [1] says that its bounds for the 96-bit nonce case is tighter than the bounds from the original proof [0]. So, it seems strange to use [1] to refute the above claim from [0], when in fact [1] strengthens [0] for the case of 96-nonces, which is what TLS uses. The claim may be true. But I'm saying 2^-18 is insufficient. > > [0] https://eprint.iacr.org/2004/193.pdf > >> > [1] https://eprint.iacr.org/2012/438.pdf >> > [2] https://eprint.iacr.org/2015/214.pdf > > > [3] https://www.ietf.org/mail-archive/web/tls/current/msg18240.html > > Cheers, > Brian > -- > https://briansmith.org/ > --001a114920f8c52eb805270b7e6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Dec 16, 2015 5:26 PM, "Brian Smith" <brian@briansmith.org> wrote:
>
> Watson Ladd <watsonbladd@g= mail.com> wrote:
>
>> Brian Smith <brian@bria= nsmith.org> wrote:
>> > So, if [2] is correct, then we can take Watson's 2^36 and= multiply it by
>> > 2^17 to get 2^53 bytes as the limit? It seems so, since [2] c= laims that
>> > they've improved the bounds by 2^17. Note that 3 out of 4= of the authors of
>> > [2] are the same authors as [1], which is the paper that defi= ned the formula
>> > that the 2^36 number was calculated from.
>>
>> You need to actually read the papers and understand which formulas= are
>> modified. If you did you would see the improvement is in AES-GCM w= ith
>> funny nonce sizes, not the confidentiality issue.
>
>
> Great. Thank you for pointing out my mistake. First, I'll correct = my mistake in understanding [2]. Then, I'll verify your derivation how = we can get the "2^36 bytes" figure. Lastly, I'll ask whether = the initial premise under which we derived that number is meaningful. In pa= rticular, many people seem to be using a limit of 2^-18 for the attackers d= istinguishability advantage to allow (over) 2^48 bytes to be sent, but the = 2^36 limit we derived comes from using the number 2^-60 instead. But, is 2^= -60 really the right number to use? It seems like we can likely tolerate a = much higher probability of distinguishability. However, it isn't clear = what probability of distinguishability is sufficient. In other words, there= is a tension between the strictness in demanding proof of IND-* security v= s. the simplicity of the protocol (rekeying or now) for AES-GCM. I believe = it is worth asking more cryptographers for help in determining this limit.<= /p>

We've already decided to add a far more complicated supp= ort for new authentication. Reykeyinh is not that complicated.

>
> First, my mistake in understanding [2]: The improvements to [2] are fo= r Theorem 1 in [1], which is about AES-GCM in general, for all nonce length= s. However, [1] also defined Corollary 3 that tightens the bound for the ca= se where the nonce length is 96 bits, which completely avoids the term with= factor 2^22. So, the 2^17 improvement in [2] for Theorem 1 is not relevant= because we're using Corollary 3, which is already even tighter. Sorry = for wasting people's time with that.
>
> Second, let's go back to how we got 2^36. We used Corollary 3 from= [1], which has this formula:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.5(=CF=83 + q + 1)^2 / 2^n
>
> We rename =CF=83 to s:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.5(s + q + 1)^2 / 2^n
>
> substitute n =3D=3D 128:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.5(s + q + 1)^2 / 2^128
>
> and simplify:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (s + q + 1)^2 / 2^127
> =C2=A0 =C2=A0
> we get the formula in Watson's email [3]. In that email, Watson th= en claimed that we want to keep this quantity under 2^-60:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (s + q + 1)^2 / 2^127 < 2^-60.
>
> Simplified:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (s + q + 1)^2 < 2^67.
>
> Further simplified:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 s + q + 1 < 2^33.5.
> =C2=A0
> So, Watson's point in [3], as I understand it, is that even if we = ignore q, s must be less than 2^32. 2^32 blocks * 2^4 bytes per block =3D 2= ^36 bytes in order to have a proof of=C2=A0IND-* security for AES-GCM, So w= e'd need to send 2^36 or fewer bytes to have proven IND-* security.
>
> Lastly, let's reconsider Watson's claim in [3] that=C2=A01/2^6= 0 is the correct bound. In [0], the authors wrote: "To provide a concr= ete example, these results show that, if AES is indistinguishable from a ra= ndom permutation, and fewer than 2^48 packets are protected, then the attac= ker=E2=80=99s advantage is no more than 2^=E2=88=9218." This implies t= hat David thought that 2^-18 was a sufficient bound.

There are likely to be over 2^40 tls connections globally.

>
> Note that even the conclusion of [1] says that its bounds for the 96-b= it nonce case is tighter than the bounds from the original proof [0]. So, i= t seems strange to use [1] to refute the above claim from [0], when in fact= [1] strengthens [0] for the case of 96-nonces, which is what TLS uses.

The claim may be true. But I'm saying 2^-18 is insuffici= ent.
>
> [0]=C2=A0https://epri= nt.iacr.org/2004/193.pdf
>
>> > [1] https://= eprint.iacr.org/2012/438.pdf
>> > [2] https://= eprint.iacr.org/2015/214.pdf
>
>
> [3]=C2=A0https://www.ietf.org/mail-archive/web/tls/current/msg18240.h= tml
>
> Cheers,
> Brian
> --
> https://briansmith.org/
>

--001a114920f8c52eb805270b7e6d-- From nobody Thu Dec 17 00:19:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9696A1A8906 for ; Thu, 17 Dec 2015 00:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-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 LECOB3WCTsVL for ; Thu, 17 Dec 2015 00:19:25 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FA611A1B64 for ; Thu, 17 Dec 2015 00:19:25 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 95A9091FCD; Thu, 17 Dec 2015 08:19:24 +0000 (UTC) Received: from dhcp-10-40-3-124.brq.redhat.com (dhcp-10-40-3-124.brq.redhat.com [10.40.3.124]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBH8JLwt005253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Dec 2015 03:19:22 -0500 Message-ID: <1450340361.7118.5.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Brian Smith , Eric Rescorla , Watson Ladd Date: Thu, 17 Dec 2015 09:19:21 +0100 In-Reply-To: References: <87twnibx5p.fsf@latte.josefsson.org> 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.27 Archived-At: Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Thu, 17 Dec 2015 08:19:26 -0000 On Wed, 2015-12-16 at 09:57 -1000, Brian Smith wrote: > Therefore, I think we shouldn't add the rekeying mechanism as it is > unnecessary and it adds too much complexity. Any arbitrary limit for a TLS connection is almost guaranteed to cause problems in the future. We cannot predict whether 2^x should be sufficient for everyone, and I'm pretty sure this will prove to be a terrible mistake. TLS is already being used for VPNs and transferring larger amounts of data in long lived connections is a reality even today. The rekey today happens using the reauthentication mechanism, which has very complex semantics. Converting these to a simpler and predictable rekey mechanism would be an improvement. regards, Nikos From nobody Thu Dec 17 03:07:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9611ACD0C for ; Thu, 17 Dec 2015 03:07:32 -0800 (PST) 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 cpxFsVPSxtrF for ; Thu, 17 Dec 2015 03:07:31 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02BA11AC416 for ; Thu, 17 Dec 2015 03:07:31 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id l126so16050627wml.0 for ; Thu, 17 Dec 2015 03:07:30 -0800 (PST) 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=K3RsoDrWkw1+WhE0llroOSE2BSU2a75qc1WLE0dJv6Y=; b=LOnfoVw6QgJOWWBOrW2+6Asq5Bd551Ryf4dbEiOsgDqyhH3wP76DJNgERRSR/dWxjP tAjp5UjOc3lIZaDW8v95Y0kgUwD5tMfBD/NIEbufVttERI9zVErVHwGg/bdCDmKsjmOu YlGL295m4iLmHGd+WldnSt3cnQNz6nu/nybt7NFWcJ/5u9BXKnNrt3bIs3VDJTZJ47Uy ii8FbpXBlsw9V6VGn76JyLJpBQ/0q+xW0oh+iDu3phO1U0UmVCpeyPPrN96sGuDrfwjl GK7W5eZL5En9VaobKqCJKm08RNetZEmZyk9HUhKFyqjeYh3y2bGwHQ6aTZsdujKFHS/L SBZg== X-Received: by 10.28.139.206 with SMTP id n197mr3189765wmd.20.1450350449574; Thu, 17 Dec 2015 03:07:29 -0800 (PST) Received: from [172.24.248.186] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id 198sm1837199wmr.18.2015.12.17.03.07.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Dec 2015 03:07:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <1450340361.7118.5.camel@redhat.com> Date: Thu, 17 Dec 2015 13:07:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87twnibx5p.fsf@latte.josefsson.org> <1450340361.7118.5.camel@redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" , Simon Josefsson Subject: Re: [TLS] Data volume 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: Thu, 17 Dec 2015 11:07:32 -0000 > On 17 Dec 2015, at 10:19 AM, Nikos Mavrogiannopoulos = wrote: >=20 > On Wed, 2015-12-16 at 09:57 -1000, Brian Smith wrote: >=20 >> Therefore, I think we shouldn't add the rekeying mechanism as it is >> unnecessary and it adds too much complexity.=20 >=20 > Any arbitrary limit for a TLS connection is almost guaranteed to cause > problems in the future. We cannot predict whether 2^x should be > sufficient for everyone, and I'm pretty sure this will prove to be a > terrible mistake. TLS is already being used for VPNs and transferring > larger amounts of data in long lived connections is a reality even > today. The rekey today happens using the reauthentication mechanism, > which has very complex semantics. Converting these to a simpler and > predictable rekey mechanism would be an improvement. Agreed. The alternative to having a rekey mechanism is to push the = complexity to the application protocol, requiring it to be able to use = more than one connection to transfer all the data, which may require = some sort of session layer to maintain state between connections. So unless we can guarantee or require that every algorithm we are going = to use is good for some ridiculous amount of data (2^64 bytes may be = enough), we need rekeying. Yoav From nobody Thu Dec 17 07:09:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DB21B2E80; Thu, 17 Dec 2015 07:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 SQyqkvo6kVdh; Thu, 17 Dec 2015 07:09:52 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C965B1B2E94; Thu, 17 Dec 2015 07:09:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 18618BEB5; Thu, 17 Dec 2015 15:09:49 +0000 (GMT) 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 VYiopwFcVdK0; Thu, 17 Dec 2015 15:09:47 +0000 (GMT) Received: from [10.87.48.95] (unknown [86.46.31.96]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BBBE2BE8F; Thu, 17 Dec 2015 15:09:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450364987; bh=o+m/WqBNvefCjLroUytRNTdWtOX6HkIZHo5lezWgBbQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=pKmecPPxgCqBKSXwuTf0G9htby5papQmsH2828PlhtQtxz5B7Zk2iR/4/fISxXw9V X2MrhvdxBht/yETskuHzqnTbWvKm8JIqLS9I/sI6PHG5jXz0idhGlh15fZ/MvelRdS jPSgOWYwe9aTdN9Ro7lOy1bfRiwI5kpZD0wgkuQk= To: Kathleen Moriarty , The IESG References: <20151217145835.20836.344.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5672D03A.8050609@cs.tcd.ie> Date: Thu, 17 Dec 2015 15:09:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151217145835.20836.344.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-tls-cached-info@ietf.org, tls-chairs@ietf.org, tls@ietf.org Subject: Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-cached-info-20: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2015 15:09:54 -0000 On 17/12/15 14:58, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-tls-cached-info-20: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Just a quick comment, sorry for asking this late and I won't hold up on > it either, just want to raise the question without quite enough time to > research it all. > > I see the SHA-256 truncation is just 32 bits. In other applications, > about half is what is typically recommended. I know you are trying to > cut on space, but will problems arise from this shorter value? Nah, I think this one's ok. IIUC, the result of a collision is just a handshake fail, and then presumably recovery when they ditch the cached stuff. Section 5 describes this. S. > > From nobody Thu Dec 17 07:13:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03731B2E97 for ; Thu, 17 Dec 2015 07:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 F1qfI02ujcvr for ; Thu, 17 Dec 2015 07:13:18 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876EB1B2E94 for ; Thu, 17 Dec 2015 07:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=945; q=dns/txt; s=iport; t=1450365198; x=1451574798; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=c89mwiW8h7IdQ3DJdB88O0Z0XJNDeWqPT8djPelDzlE=; b=G9BFDa9cF7IByUPgiCVCOz6samzlGx7BSMSQhS8yQxTG58DshszRQLgT nmLMI+TlHPtmYklUMd81WjeNyJvKr74B5XxjqTcrwzzdEjtVbmjhdrl// E+030EhKtHVmuy5CFnZZTWDqRLt1BajrUO/0wHKw+80yMS++ZBXWeyk39 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQBP0HJW/4MNJK1egzpSvl4BDYFiI?= =?us-ascii?q?YVsAoE2OBQBAQEBAQEBgQqENQEBBDhAARALGAkWDwkDAgECAUUGDQgBAYgrDr0?= =?us-ascii?q?rAQEBAQEBAQEBAQEBAQEBAQEBARYEi1SCcYFRhH4BBI4tiFCFOYgPgVyHSosVi?= =?us-ascii?q?GIgAQFChCKFUAEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,441,1444694400"; d="scan'208";a="219145613" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Dec 2015 15:13:17 +0000 Received: from [64.102.56.172] (dhcp-64-102-56-172.cisco.com [64.102.56.172]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tBHFDHhP002112; Thu, 17 Dec 2015 15:13:17 GMT To: Dave Garrett References: <56718D7A.4000302@cisco.com> <201512161530.06122.davemgarrett@gmail.com> <5671D454.6000506@cisco.com> <201512161628.02986.davemgarrett@gmail.com> From: John Foley Message-ID: <5672D12D.4010003@cisco.com> Date: Thu, 17 Dec 2015 10:13:49 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <201512161628.02986.davemgarrett@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Explicit use of client and server random values X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2015 15:13:20 -0000 On 12/16/2015 04:28 PM, Dave Garrett wrote: > On Wednesday, December 16, 2015 04:15:00 pm John Foley wrote: >> Thanks for answering my questions. Have you considered adding KAT >> values for the key derivation steps? This would be helpful to >> implementors. RFC5869 already has KAT values for HKDF-Extract and >> HKDF-Expand. But the TLS 1.3 spec has added HKDF-Expland-Label. >> Additionally, It would be useful to show intermediate KAT values for >> xSS, xES, mSS, and mES. > I suggest filing an issue or submitting a PR with a starting point set of changes and discussing it with ekr. > I've submitted https://github.com/tlswg/tls13-spec/issues/378. If you give me a few days, I'll update this issue with KAT values per revision 10. Since it sounds like there are changes forthcoming in this section of the draft, I'll hold off on the PR until later. Hopefully someone else will volunteer to verify my KAT values. From nobody Thu Dec 17 11:14:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66EE1A886C for ; Thu, 17 Dec 2015 11:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.112 X-Spam-Level: X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 HWfus1EudI4y for ; Thu, 17 Dec 2015 11:14:31 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (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 712C71A8729 for ; Thu, 17 Dec 2015 11:14:31 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id C15961ECE6; Thu, 17 Dec 2015 19:14:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1450379670; bh=xldQ6wXCa81uIhxdAZklxBsJFhtZjNMxfpNjvSlygFQ=; h=From:To:Subject:Date:From; b=ez7sTtSKJjP8uldNeciK5eSrRsw7J+DGdyIFP0hSumooRLTdnbTCVcQVwhgQm8q/u MCgz4//eQT290F+poyerc2SQVNbNv1X3S45m38hGZ2+gfP/qZWe4cHHQaT/U+XkSXS F8K/f+W69ERBr08Cp4BsvsZy5reVwS93jx/piahk= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 39C1D107AC44E; Thu, 17 Dec 2015 19:14:18 +0000 (UTC) From: James Cloos To: tls@ietf.org User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 17 Dec 2015 14:14:18 -0500 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:151217:tls@ietf.org::KibSoMiSuQfb5ipD:00003GFZK Archived-At: Subject: [TLS] Poly1305 vs GCM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2015 19:14:33 -0000 Given the issues w/ gcm currently under discussion, and that poly1305 was originally proposed to use w/ aes, should tls recommend aes-poly1305 instead of aes-gcm for those who want to continue to use aes? Or does chacha-poly1305 not fall victim to the 2^36 attack not because of the aead but rather because of chacha? -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Thu Dec 17 11:27:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B091B302D for ; Thu, 17 Dec 2015 11:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 nJaCReaXKgAb for ; Thu, 17 Dec 2015 11:27:26 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id AC2941A8902 for ; Thu, 17 Dec 2015 11:27:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id C3AB77DF; Thu, 17 Dec 2015 21:27:24 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id W91GdXKBwhY7; Thu, 17 Dec 2015 21:27:24 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 814CF1F8; Thu, 17 Dec 2015 21:27:24 +0200 (EET) Date: Thu, 17 Dec 2015 21:27:20 +0200 From: Ilari Liusvaara To: James Cloos Message-ID: <20151217192720.GA22714@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Poly1305 vs GCM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2015 19:27:30 -0000 On Thu, Dec 17, 2015 at 02:14:18PM -0500, James Cloos wrote: > Given the issues w/ gcm currently under discussion, and that poly1305 > was originally proposed to use w/ aes, should tls recommend aes-poly1305 > instead of aes-gcm for those who want to continue to use aes? > > Or does chacha-poly1305 not fall victim to the 2^36 attack not because > of the aead but rather because of chacha? AFAIK, there are two possible reasons for the difference (one or both may contribute): - Chacha20 is PRF(unction), AES is PRP(ermutation). - Chacha20-Poly1305 has per-packet r and s, AES-Poly1305 and AES-GCM only has per-packet s and per-key r (as originally proposed). -Ilari From nobody Thu Dec 17 12:01:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E998A1B307A for ; Thu, 17 Dec 2015 12:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_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 WuE-8lP8dP_a for ; Thu, 17 Dec 2015 12:01:50 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DF4D1B3067 for ; Thu, 17 Dec 2015 12:01:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RJ1qwYgEFuyBLyDcj1bJ4UchXFdwsoC/0/wQoVBFiak=; b=U2RTKfjGh3UEZiDP1lsb/V9Fibiu1xZ96txlGxmlbjN+xCUP/s0OYx0lFJEMO2mLjp4VrQN9tMj1M0uJj+DX9o5M6W6xM85dJK1JBpV2GmLQXiTbff99YMeQptRmnWL1ewxS6wAErPCGzzhXGxWIMrZHaY4VEC/RW6oNglKSqwQ= Received: from BN3PR0301CA0041.namprd03.prod.outlook.com (10.160.180.179) by BN1PR0301MB0724.namprd03.prod.outlook.com (10.160.78.143) with Microsoft SMTP Server (TLS) id 15.1.355.16; Thu, 17 Dec 2015 20:01:20 +0000 Received: from BL2FFO11FD044.protection.gbl (2a01:111:f400:7c09::113) by BN3PR0301CA0041.outlook.office365.com (2a01:111:e400:4000::51) with Microsoft SMTP Server (TLS) id 15.1.355.16 via Frontend Transport; Thu, 17 Dec 2015 20:01:20 +0000 Authentication-Results: spf=pass (sender IP is 206.191.249.68) smtp.mailfrom=microsoft.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=microsoft.com; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.249.68 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.249.68; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.249.68) by BL2FFO11FD044.mail.protection.outlook.com (10.173.161.140) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Thu, 17 Dec 2015 20:01:18 +0000 Received: from AM3PR30MB049.064d.mgd.msft.net (141.251.48.82) by AM3PR30MB049.064d.mgd.msft.net (141.251.48.82) with Microsoft SMTP Server (TLS) id 15.1.337.9; Thu, 17 Dec 2015 20:01:16 +0000 Received: from AM3PR30MB049.064d.mgd.msft.net ([141.251.48.82]) by AM3PR30MB049.064d.mgd.msft.net ([141.251.48.82]) with mapi id 15.01.0337.009; Thu, 17 Dec 2015 20:01:16 +0000 From: Cedric Fournet To: "tls@ietf.org" Thread-Topic: Re: [tls13-spec] resetting the sequence number to zero for each record key. (#379) Thread-Index: AdE5BDjhcI4FV8x0QyKuaccyaVLWlA== Date: Thu, 17 Dec 2015 20:01:16 +0000 Message-ID: <5e85e3b1a1914ea8bbd5d985c321c119@AM3PR30MB049.064d.mgd.msft.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.251.50.132] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD044; 1:F6FfL0o9ocKu9QybLFe8BJ5Ab8pTrgLsuC2eI65SwWiUXLKhOTdMJ0pCHNRpSrzfgTc42OWpaKPF22LC0xIs50sVTFeIM6B0X0LMS3Yrr7QYjE9kEe4FoH1Z2uJWkgTYehLr3fY1TMQXpjpyAje0Vroa66EM9dOpTdYgh6PTLJTVN8q+PaR41h+oHiVufEdiC9p+Gqbjfywa4I4D/k/WTZHWiXcaj4NYxp0lUV9hEG9KVfqge6VLOlpxqWTvff1OkW08teaztkYTNpf/vrdOXzdO+3ZVK2xkPDLWbk/2pBniZlb5HazFYlj9Cv8YB5IJr4dG990Q3Iy/cFZB0L3NBg== X-Forefront-Antispam-Report: CIP:206.191.249.68; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(199003)(189002)(24736003)(16796002)(4001430100002)(6806005)(2501003)(92566002)(54356999)(87936001)(15975445007)(47776003)(1220700001)(6116002)(3846002)(66066001)(1730700002)(102836003)(86146001)(1096002)(189998001)(10400500002)(11100500001)(26826002)(33646002)(107886002)(5005710100001)(106466001)(81156007)(5008740100001)(50986999)(97736004)(5001960100002)(561944003)(5003600100002)(110136002)(5004730100002)(108616004)(10290500002)(86612001)(586003)(23746002)(69596002)(2351001)(10090500001)(19580395003)(50466002)(86362001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0301MB0724; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1PR0301MB0724; 2:AApIYWDE4UtUR/jDj1kDr5VFgPC12woqFRYGv2gm8cdS2KLbc0VbEAqT4COB7BRnytRwypH5IIwrVfL0/ha5rllmy0IYQrzNvD5lZROM1t1JkJ2uBu26U/CQgewU7vUqRfl5AvQ3jcYvEPgqp7LxFw==; 3:pcmwGbnvmxXX43QphJ+GnrSPRlgdD6QY6qMhZ30EivlHD9auOidqA3t7hqba6AtAfrtErcunQkmUH48OriPpkWoLe4MCeJREzZdDYkUkvGE+BZvhfmzBmZRHYD7Lo5iBk2lrm2nAchpiqda6L42iUTv+Xk6mgTv8+8AAPp7iPHIoTDAExquDCPhK0XZus6btKLYZ87pXG1HgvQFBAHsg/izPsaiKHc01eNkrwvcMFPR+zajD4ziLtA/Vb9P05NCH1lJVs3wBeMcW5hbhdcadCg==; 25:hBiom5UtbZuMfjgLCGXQVpFdrGFblHahZ6O8KD77wKnBxzfVpyBe904WitRFM15QSwhTmbbJNPq/Ckm6aOgqzxb7Y+z/bhJzr+KJeHNlvZY+sbDhMjNVmF2Y3RJccGdchpHTcJtdE4tDQsLJboTXufK80bW8O0qXzDQP+P7hGfiT9nHB/7Xv4SMch1P8yBY95OpJD4vYPyvUa8VDDkEcnIB2t6XCC4+ODGce1Ql0blq//lcU8ZB/5X82UNWKAw1yuZZS6zaGhJQoyRLcb5JrV7jSR4U2k4w1i/OqppSb2SE= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:BN1PR0301MB0724; X-O365EOP-Header: O365_EOP: Allow for Unauthenticated Relay X-Microsoft-Exchange-Diagnostics: 1; BN1PR0301MB0724; 20:je9osmWp9LI78Xqv+jLS6mZCNY2CUxmKm1Y6BpOJwX79Wc2KOt4lGiwAYvofZvHB9DxSNjwBF3HwGOujggNvsAmlvOkONHQAFHeV3dU+WECWGW6WoPVv4XiywOT1MQKrTBOODwCst50Xta5e3YJkMsYjpH9ybKFes5POWzPNy4TVKWHWAhoZrT3N9BXf0FaoGcg1EY93S2OqfJtua9d9+K3q0EPihCnhpxfwtXIXYSvF1fq4RlhYhbPPE4tyy5eHlJs5FnMKRIdCV7ix7nqurGx71Q9nOBYQ7XCIXxtHdldGHdZ7H0J3HEUQCscbwObMRuVrfSCeCj/3zj6d0a/OACp7UTl4AN3l3yNbKfM6OdaFnqVVvOuD0r+MbPQHOIVAurKRc90By/Hzk2hvjBEZEMutaTa0N4uhEX2vxEB5aJzsxFQfmgsucu+Eh+e/OKMP1tM5AaiK8uqQHblG6bOTMWqcfGauA3EBjCp04vrOb2orGyulGZ8UDHQki1Dadg2IiBrUfDR6iKYMpOT16HV7H/IJKN0U7zw75WKfqc9JdMvZZbEnJd+6pQQ003G/KWEjZ/XSwUOq4R7w2J7Msqhnm9s3JM2lXm8KtDpGjObLlEQ= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BN1PR0301MB0724; BCL:0; PCL:0; RULEID:; SRVR:BN1PR0301MB0724; X-Microsoft-Exchange-Diagnostics: 1; BN1PR0301MB0724; 4:I5YiB3NLkwYn5Q0Dfc74ZZ/8xcKBBDHvihtIS44UGBhzkN1a73Gzn4mMauJL04091bfPi1MlwKEdSb4aC+EnKek4SiMXuf87v1stsJJxQ2BigmMaiXpgQUPI9twHSix3mAIaSQBio/nEIHNGI45Ck5c5TeBJBvXAAMBCQAEgvt9pyl3G63EyoFjHHlqeUCASRueZsI2YcI8W/+X6H88lUshvRJXht3+8xuQ/bFbIm0/ByQXi2Y8DFAMzuFIHeALWwir/ZVvvlbyegz6WQl0tAXjn+oOtlNd2claqMW1jV3mk8tIaStrdDQVu6BecVE8Mzb6NLOhtVNKScMJBVUUZUQdr+bycS+HbCao5Nbm+wk2aqgdrrT3L+dswc/HAD9ZV/ixnn4Dcg50bm6CI2w5blVxZad9mTNPs7iMIf2j1E6m7JZLFmaznj5iMXqqozMuC X-Forefront-PRVS: 07935ACF08 X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BN1PR0301MB0724; 23:omrYoacUNjAvpN4hLaz7+cWTK8DBwZ2TcWR?= =?Windows-1252?Q?UCHTdp8pNj7b6z3I1BKJwMg3SbUdyPviWioPXFXRcKtRBfTTAuMJFlWL?= =?Windows-1252?Q?mwVQO2z5SVmV831xEwp/cVhXaTNQ6KtMsQPSBQOgLOwJOpoiDIvX8G9p?= =?Windows-1252?Q?gidNVCQfr6SOv6YS2YFuLvq/PEU4Q/97F8OamjZvF7/qkbfxnId2sbPE?= =?Windows-1252?Q?BFyB1DojRfvH1ZpMR1+FsH0iFhb9ZFSb1CA7tPc61EuBnCwxjw6zZI+z?= =?Windows-1252?Q?3JwbqT/G5BICPH76lAjDJqtrn/VIj+Iu6cMtYbt97dx196FKfbOuvhgA?= =?Windows-1252?Q?ble/KA+znpyNtNTylsfOXBpy0l7ojCd1v8TciPcHSf0cJaIaQlh/2Z3L?= =?Windows-1252?Q?L38I3UbDCxUam9aS4PZ5sKGFb48I1l5ODh+LuI3tORrnDRSfjhP8eNBs?= =?Windows-1252?Q?38oY3EoJJ2rgujhun7CtE5T6ZrfbYDa9xhOjkAva64geu9RQ6x6A9JFD?= =?Windows-1252?Q?MJRO99+Wg6SBh6896dJevJc3tEhyVpOJFGuqRJIlgmq0Cyx7DoRCza4F?= =?Windows-1252?Q?re9zCoraLtiS5qzktFQ7wWDg2ZBeqD0YQS6EC80gDhs24C0L+K3oCc2q?= =?Windows-1252?Q?2rSjH5xH9sYGhWITtsN8aPqRhgBGoXHkVF4jdUWW6ZtODZBZph9CYPep?= =?Windows-1252?Q?C9bwWWupngllcGnckU7IWwsJTEWtHuOSNXQRmT4c/OpJqZjjbfEfyyuO?= =?Windows-1252?Q?ci27riEx0a/vGuhUK5A1BoiHZ6UvRRc307pb2P+S3bW/6IyBee3lb82F?= =?Windows-1252?Q?pdUffS/WfatovQ3UTa0m2ltzqQOWl3EI15v5ssCgDzk0vIikpphVoBBe?= =?Windows-1252?Q?G6GkqHQv5jzBwpNtjBt/LAP+VUde18GbGf5vm+p9+5NrsJx8Q/ZCNpgG?= =?Windows-1252?Q?t1dipTkLEAMVu9CFY/4GigHRfuHthJOPv80XG9ZOF2kb8DYZvyQGgUsz?= =?Windows-1252?Q?3VIDLwmwm5PmAxNy6LNeD4UCI/ZECeMem/b/1SnP5WPuWFJesqmu4LQG?= =?Windows-1252?Q?ekg4/UMbOMmRGIU0hemXCOcEo68/STh44irqxikxrw+BkkLoUAbMzK5S?= =?Windows-1252?Q?R37Gkx9P/2Bpx4qpyaeEOT/CsQD77cIVTFcROXhfdbxQtUOXwrM8V3TD?= =?Windows-1252?Q?CYi7n3hCPFUYX5404Z29P2PeeQerl/deGrsnxn/uYAo71ADIH8fYyj2g?= =?Windows-1252?Q?Lng7albIokd1M0vPjUWVmhG+Za6FsIzVp12jrS1eiEcj4BC8xgrLJjlM?= =?Windows-1252?Q?hW3kEU9C5jqPkHLRXQCupcH8BtJMbW4EI/kOEuaXVVrb4u5lb2BsI9sN?= =?Windows-1252?Q?QQIgTBTAJTwJPJZRv+fwFeI41kRH3vFQP2tCff6u31i/YfMDc6VTKHVL?= =?Windows-1252?Q?HjVapcIdqAmpQA7WBh3cC4MkQGGTOjW8Zv3FjuuOvpQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR0301MB0724; 5:rLewX4gOlVvFYqFbuICzKDtfzPSPr6KZUeCSGi7PKwURDzapl/8NwupOqlHUWku3h5+BonN4MbB77vBEbQSEB5tGESixCzRVNUopJDqHCvGdBEDAUvJKPhL1GVZQQvNDQEvZBte2Kgfxd6bKagFikg==; 24:u7NqWBGREd2a5lpXXFbhXpGDDnESJW1eYBx34kXQ/HXpbgFJY9BApkxL1swqlFI/HhBt4tr4lFWOIu1Yn7ekCoZmr1P/gi7F7+9eMxzu4S4= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2015 20:01:18.1516 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.249.68]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR0301MB0724 Archived-At: Cc: Antoine Delignat-Lavaud , Karthikeyan Bhargavan Subject: Re: [TLS] [tls13-spec] resetting the sequence number to zero for each record key. (#379) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2015 20:01:56 -0000 As explained below, we propose that the record-layer sequence numbers be reset to 0 whenever new keys are installed (as in TLS 1.2): https://github.com/tlswg/tls13-spec/pull/379 C=E9dric Fournet, on behalf of the miTLS team. While working on a formal model of the TLS 1.3 record layer, I bumped into a new weakness due to the chaining of sequence numbers between epochs. In the current draft, the sequence number is not reset when a new key is installed. This is a new mechanism we suggested a while ago: the intent was to prevent suffix truncations of traffic encrypted with the old key by making the first decryption with the new key fail. This mechanism prevents suffix truncations when *both* keys are secure, but it introduces a new weakness when the old key is compromised and the new key is secure. Then, the attacker gains the ability to delete the first few fragments encrypted with the new key, which we think is not acceptable. This is problematic when switching from the 0RTT keys to the handshake keys, then to the application keys, as the whole point of the TLS 1.3 key schedule is to gradually establish stronger keys. We discuss below some of the complications it may cause. PREFIX TRUNCATION: HANDSHAKE ---> APPLICATION This weakness in the transition from the handshake key to the application data key may be exploited as follows: * The client and server complete a 1-RTT handshake, and some implementation bug causes the handshake key to be leaked. * The attacker may play with handshake message fragmentation to artificially increase the sequence number on either side of the channel. The handshake data remains untouched, so the handshake can still be successful.=20 * When the client and server start exchanging application data (using the new, secure key), the attacker can remove as many fragments as he added to truncate application data in both directions! PREFIX TRUNCATION: 0RTT ---> HANDSHAKE=20 A variant may also occurs during the change from the 0-RTT key to the handshake key: * The client first sends 0RTT-encrypted fragments, then handshake-encrypted fragments. * The attacker breaks the 0RTT key, and rewrites 0RTT traffic to insert additional fragments, for instance by fragmenting the 0RTT payload into several fragments. For each additional fragment with the old key, it also deletes a fragment encrypted with the new key, and then forwards the rest of the client traffic unchanged. * The server's sequence number is higher than the client's when it changes key, but nonetheless the server successfully decrypt all received fragments. Similarly, if the server refuses 0RTT but continues the handshake, it is unclear which sequence number the client should use for encrypting handshake traffic. If the client continues with the 0RTT sequence number, then the only way for the server to decrypt the handshake traffic is to count how many 0RTT fragments it discards---and this can be controlled by the attacker, even without breaking the 0RTT key! Although prefix truncations will probably cause the handshake to fail, this complicates the analysis of the record layer, whose security now depends on the details of the handshake protocol. There are also corner cases; for instance, assuming alerts are protected using the current keys (as they are in TLS 1.2), it may be possible to silently delete a warning from the client to the server, or to truncate half of the client certificate and observe whether the second half starts with a well-formed alert fragment. OUR PROPOSAL. In the current draft, the ends of encrypted traffic have now all be made explicit (using end_of_early_data; Finished; and close_notify), so there is no apparent need to chain sequence numbers. We propose to revert this change (that is, to reset the sequence number each time a new key is installed, as in TLS 1.2). If the chaining is still required for some other reason, one could instead include the old sequence number in the new key derivation (or the new key's additional data, but we believe this is no longer an option). From nobody Thu Dec 17 12:03:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1A31B3064 for ; Thu, 17 Dec 2015 12:03:19 -0800 (PST) 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 7MhD5CxfRytO for ; Thu, 17 Dec 2015 12:03:17 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3FB21B3062 for ; Thu, 17 Dec 2015 12:03:15 -0800 (PST) Received: by mail-lb0-x231.google.com with SMTP id kw15so52030336lbb.0 for ; Thu, 17 Dec 2015 12:03:15 -0800 (PST) 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=zoVGQhl4Z9NsjtphIz6LSv/O9Rq0WX8RMDLkM9ajO6M=; b=WJcnZVeCpVvfmdU9lHFvv+9t6pb1OapvNJI+7kYUO3yYIgB5eg/iZ9Sd27THeO1KQj DmjFv/KCDXEh3QNPWcb4DOp/g5pZRqS07LIHIFMcrVBSCcnU8Fg5Re4Z1thYSl3wqiGW aBe4j8SZT3lKVCrQH5I01aBNKbFys/tlWwkNs7aVuIrt8zCEeJRLAdW4sUb8lgsYegHW 3qZd5ANoSEZVp8VBIoEMUorFnb8L7gVTwMGaG+zqeGkaDTc7Y4DAtb8Almjlq1+CdBxU qevmFAzSry2dktSwGikgwk5b7K6GjXZBUungbcoaXpHsJgUjX/byOoBgY69Tz1q9u5GD 32Wg== X-Received: by 10.112.168.133 with SMTP id zw5mr22304307lbb.95.1450382593991; Thu, 17 Dec 2015 12:03:13 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.168.210 with HTTP; Thu, 17 Dec 2015 12:02:44 -0800 (PST) In-Reply-To: <5672D12D.4010003@cisco.com> References: <56718D7A.4000302@cisco.com> <201512161530.06122.davemgarrett@gmail.com> <5671D454.6000506@cisco.com> <201512161628.02986.davemgarrett@gmail.com> <5672D12D.4010003@cisco.com> From: Hugo Krawczyk Date: Thu, 17 Dec 2015 15:02:44 -0500 X-Google-Sender-Auth: H1eZUUzChpxNU4JV5hg1y4wTiAo Message-ID: To: John Foley Content-Type: multipart/alternative; boundary=001a11c2345e4dab2f05271d831d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Explicit use of client and server random values X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2015 20:03:19 -0000 --001a11c2345e4dab2f05271d831d Content-Type: text/plain; charset=UTF-8 I have mentioned this in private conversations but let me say this here: I would prefer that the nonces be explicitly concatenated to the handshake hash. That is, handshake_hash = Hash( client random || server random || Hash(handshake_messages) || Hash(configuration) || ) The reason is that nonces are essential for freshness and session uniqueness and I want to see them explicitly included in the signed/mac-ed/KDF-ed information. I can envision a future variant/mode of the protocol where parties do not transmit nonces but have a synchronized state that they advance separately and use as nonces (e.g., for key refreshing) - in such case the nonces would not be included in the handshake-hash computation. So while the redundancy of having them twice in the handshake_hash calculation may be annoying, this adds robustness to the security (and analysis) of the protocol. Another reason for including them (in particular as the leading values) in the computation of handshake_hash is to have them always located at the same position in the hashed stream. It is needed to make sure that these streams are unique per session (in theory, and maybe in practice, an attacker may play games changing the boundary of nonces by changing surrounding bytes in the stream). If this augmenting of handshake_hash is not adopted then there should be a note cautioning against excluding the nonces from the transmitted messages. If possible, it would be good to move them to a fixed position (from the start of the input to the handshake_hash). Hugo On Thu, Dec 17, 2015 at 10:13 AM, John Foley wrote: > On 12/16/2015 04:28 PM, Dave Garrett wrote: > >> On Wednesday, December 16, 2015 04:15:00 pm John Foley wrote: >> >>> Thanks for answering my questions. Have you considered adding KAT >>> values for the key derivation steps? This would be helpful to >>> implementors. RFC5869 already has KAT values for HKDF-Extract and >>> HKDF-Expand. But the TLS 1.3 spec has added HKDF-Expland-Label. >>> Additionally, It would be useful to show intermediate KAT values for >>> xSS, xES, mSS, and mES. >>> >> I suggest filing an issue or submitting a PR with a starting point set of >> changes and discussing it with ekr. >> >> > I've submitted https://github.com/tlswg/tls13-spec/issues/378. If you > give me a few days, I'll update this issue with KAT values per revision > 10. Since it sounds like there are changes forthcoming in this section of > the draft, I'll hold off on the PR until later. Hopefully someone else will > volunteer to verify my KAT values. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c2345e4dab2f05271d831d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have mentioned this in private conversations = but let me say this here: I would prefer that the nonces be explicitly conc= atenated to the handshake hash.=C2=A0 That is,=C2=A0

handshake_hash =3D Hash(
client random ||
     =
                       server random   =
         ||
               =
             Hash(handshake_messages) ||
Hash(configuration) || )

The reason is that nonces are essen= tial for freshness and session uniqueness and I want to see them explicitly= included in the signed/mac-ed/KDF-ed information. I can envision a future = variant/mode of the protocol where parties do not transmit nonces but have = a synchronized state that they advance separately and use as nonces (e.g., = for key refreshing) - in such case the nonces would not be included in the = handshake-hash computation.

So while the re= dundancy of having them twice in the handshake_hash calculation may be anno= ying, this adds robustness to the security (and analysis) of the protocol.<= /div>

Another reason for including them (in parti= cular as the leading values) in the computation of handshake_hash is to hav= e them always located at the same position in the hashed stream. It is need= ed to make sure that these streams are unique per session (in theory, and m= aybe in practice, an attacker may play games changing the boundary of nonce= s by changing surrounding bytes in the stream).

If this augmenting of handshake_hash is not adopted then there should = be a note cautioning against excluding the nonces from the transmitted mess= ages. If possible, it would be good to move them to a fixed position (from = the start of the input to the handshake_hash).

Hugo

On Thu, Dec 17, 2015 at 10:13 AM, John Foley <= ;foleyj@cisco.com= > wrote:
On 12= /16/2015 04:28 PM, Dave Garrett wrote:
On Wednesday, December 16, 2015 04:15:00 pm John Foley wrote:
Thanks for answering my questions.=C2=A0 Have you considered adding KAT
values for the key derivation steps?=C2=A0 This would be helpful to
implementors.=C2=A0 RFC5869 already has KAT values for HKDF-Extract and
HKDF-Expand.=C2=A0 But the TLS 1.3 spec has added HKDF-Expland-Label.
Additionally, It would be useful to show intermediate KAT values for
xSS, xES, mSS, and mES.
I suggest filing an issue or submitting a PR with a starting point set of c= hanges and discussing it with ekr.


 I've submitted https://github.com/tlswg/tls13-spec= /issues/378.=C2=A0 If you give me a few days, I'll update this issu= e with KAT values per revision 10.=C2=A0 Since it sounds like there are cha= nges forthcoming in this section of the draft, I'll hold off on the PR = until later. Hopefully someone else will volunteer to verify my KAT values.=


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

--001a11c2345e4dab2f05271d831d-- From nobody Thu Dec 17 12:11:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB711B303E for ; Thu, 17 Dec 2015 12:11:57 -0800 (PST) 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, HTML_MESSAGE=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 EvdCjYa9fHR9 for ; Thu, 17 Dec 2015 12:11:55 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 718971A8903 for ; Thu, 17 Dec 2015 12:11:55 -0800 (PST) Received: by mail-yk0-x232.google.com with SMTP id 140so32910572ykp.0 for ; Thu, 17 Dec 2015 12:11:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ihvedxQO4cLn08qVZMgEu39GZWtaTPwzJAJyb/8LsFo=; b=Z2h8Q87WWFqVJ4lk8/y9f3QO1eE/XwyjpDHiA/6SaPpTSvlhndZWsVfLDSaRV9JUCL sY0h5ygzjta7FeWXQquRFl2bawK5dYqWZLKrsGYdi+RNZFOVBuQxYVshnkj0lvZaFF9K 54jqoWSF5Fkvi3TbFMAF9LbaRrrfsQmbdBs6cP4no8x/jX53GpWNt1kdY1kzztWWHJCO 67to5yC+noR08/13F9o/H68xNdUHfJ091YOuC4vEBZtMXqJY70Jnul5vuxCcSKlvyLVV 2a6fbGC93rz+GZhbmfw0ZyBbe1SUKdcYyEnHAgk2SvNuNdImZWJ2HwmXQD6m6zqClo4d 5YtA== 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=ihvedxQO4cLn08qVZMgEu39GZWtaTPwzJAJyb/8LsFo=; b=d1d+CqzWy2IDY4SkKyd20QwHkgdXtrnMK4qnY3PbDP0DpueQpRPEh0YdR3ymc3/L59 ny1zqQ/m623cJ2hAnYpkAi6nqUMn79XwdieE0d/2GzPMzmJxTUNScG+U5GErr7RnGc5J kpjDGIJ4UmWdUMbSoaTte1dz4YgB8ZYYiid3kdhz50tpM9bYXGt+Do9BMzv9rOY7TifX SazEGt0mP/Uz1H/xxxjeUl4YNgoCLlSJSLMqJ0vRucZpFnEdBkY4wFFioeOV+ebi9wrL 3FpHIxS12+jsFtwUNjL29Es+ag3QllvVOI/BJGCUC13jiGTmEv5Sl+fIOWu/rZY1cUL7 SqgA== X-Gm-Message-State: ALoCoQlr2CicccCMt1WRtLm4vYdN5HkTNi1Wd+ytPtejexQF1dRh6JFYmh/insjdVMzxS++hZOOGZzgytObouZ0yx+J4EPY0hQ== X-Received: by 10.13.193.4 with SMTP id c4mr19928555ywd.192.1450383114664; Thu, 17 Dec 2015 12:11:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Thu, 17 Dec 2015 12:11:15 -0800 (PST) In-Reply-To: References: <56718D7A.4000302@cisco.com> <201512161530.06122.davemgarrett@gmail.com> <5671D454.6000506@cisco.com> <201512161628.02986.davemgarrett@gmail.com> <5672D12D.4010003@cisco.com> From: Eric Rescorla Date: Thu, 17 Dec 2015 15:11:15 -0500 Message-ID: To: Hugo Krawczyk Content-Type: multipart/alternative; boundary=001a114caa9e5682b705271da291 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Explicit use of client and server random values X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2015 20:11:57 -0000 --001a114caa9e5682b705271da291 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk wrote: > I have mentioned this in private conversations but let me say this here: I > would prefer that the nonces be explicitly concatenated to the handshake > hash. That is, > > handshake_hash = Hash( > > client random || > > server random || > > Hash(handshake_messages) || > > Hash(configuration) || ) > > > The reason is that nonces are essential for freshness and session > uniqueness and I want to see them explicitly included in the > signed/mac-ed/KDF-ed information. I can envision a future variant/mode of > the protocol where parties do not transmit nonces but have a synchronized > state that they advance separately and use as nonces (e.g., for key > refreshing) - in such case the nonces would not be included in the > handshake-hash computation. > > So while the redundancy of having them twice in the handshake_hash > calculation may be annoying, this adds robustness to the security (and > analysis) of the protocol. > This change doesn't make implementation or specification significantly more difficult. Does anyone else object or feel it makes analysis harder? :) -Ekr Another reason for including them (in particular as the leading values) in > the computation of handshake_hash is to have them always located at the > same position in the hashed stream. It is needed to make sure that these > streams are unique per session (in theory, and maybe in practice, an > attacker may play games changing the boundary of nonces by changing > surrounding bytes in the stream). > > If this augmenting of handshake_hash is not adopted then there should be a > note cautioning against excluding the nonces from the transmitted messages. > If possible, it would be good to move them to a fixed position (from the > start of the input to the handshake_hash). > > Hugo > > On Thu, Dec 17, 2015 at 10:13 AM, John Foley wrote: > >> On 12/16/2015 04:28 PM, Dave Garrett wrote: >> >>> On Wednesday, December 16, 2015 04:15:00 pm John Foley wrote: >>> >>>> Thanks for answering my questions. Have you considered adding KAT >>>> values for the key derivation steps? This would be helpful to >>>> implementors. RFC5869 already has KAT values for HKDF-Extract and >>>> HKDF-Expand. But the TLS 1.3 spec has added HKDF-Expland-Label. >>>> Additionally, It would be useful to show intermediate KAT values for >>>> xSS, xES, mSS, and mES. >>>> >>> I suggest filing an issue or submitting a PR with a starting point set >>> of changes and discussing it with ekr. >>> >>> >> I've submitted https://github.com/tlswg/tls13-spec/issues/378. If you >> give me a few days, I'll update this issue with KAT values per revision >> 10. Since it sounds like there are changes forthcoming in this section of >> the draft, I'll hold off on the PR until later. Hopefully someone else will >> volunteer to verify my KAT values. >> >> >> _______________________________________________ >> 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 > > --001a114caa9e5682b705271da291 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk <hugo@ee.technion.= ac.il> wrote:
I have me= ntioned this in private conversations but let me say this here: I would pre= fer that the nonces be explicitly concatenated to the handshake hash.=C2=A0= That is,=C2=A0

handshake_hash =3D Hash(
                            client random            ||
                =
            server random            ||=

                          =
  Hash(handshake_messages) ||
                            Hash(configuration)      ||
                           )

The reason is that nonces are essen= tial for freshness and session uniqueness and I want to see them explicitly= included in the signed/mac-ed/KDF-ed information. I can envision a future = variant/mode of the protocol where parties do not transmit nonces but have = a synchronized state that they advance separately and use as nonces (e.g., = for key refreshing) - in such case the nonces would not be included in the = handshake-hash computation.

So while the re= dundancy of having them twice in the handshake_hash calculation may be anno= ying, this adds robustness to the security (and analysis) of the protocol.<= /div>
=C2=A0
This change doesn't= make implementation or specification significantly more difficult.
Does anyone =C2=A0else object or feel it makes analysis harder? :)
=

-Ekr



=
Another reason for includ= ing them (in particular as the leading values) in the computation of handsh= ake_hash is to have them always located at the same position in the hashed = stream. It is needed to make sure that these streams are unique per session= (in theory, and maybe in practice, an attacker may play games changing the= boundary of nonces by changing surrounding bytes in the stream).

If this augmenting of handshake_hash is not adopted = then there should be a note cautioning against excluding the nonces from th= e transmitted messages. If possible, it would be good to move them to a fix= ed position (from the start of the input to the handshake_hash).

Hugo

On Thu, Dec 17, 2015 at 10:13 AM, John = Foley <foleyj@cisco.com> wrote:
On 12/16/2015 04:28 PM, Dave = Garrett wrote:
On Wednesday, December 16, 2015 04:15:00 pm John Foley wrote:
Thanks for answering my questions.=C2=A0 Have you considered adding KAT
values for the key derivation steps?=C2=A0 This would be helpful to
implementors.=C2=A0 RFC5869 already has KAT values for HKDF-Extract and
HKDF-Expand.=C2=A0 But the TLS 1.3 spec has added HKDF-Expland-Label.
Additionally, It would be useful to show intermediate KAT values for
xSS, xES, mSS, and mES.
I suggest filing an issue or submitting a PR with a starting point set of c= hanges and discussing it with ekr.


 I've submitted https://github.com/tlswg/tls13-spec= /issues/378.=C2=A0 If you give me a few days, I'll update this issu= e with KAT values per revision 10.=C2=A0 Since it sounds like there are cha= nges forthcoming in this section of the draft, I'll hold off on the PR = until later. Hopefully someone else will volunteer to verify my KAT values.=


_______________________________________________
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


--001a114caa9e5682b705271da291-- From nobody Thu Dec 17 12:13:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E571A8903 for ; Thu, 17 Dec 2015 12:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 oAcLaGK26WpG for ; Thu, 17 Dec 2015 12:13:45 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id C19D31B3073 for ; Thu, 17 Dec 2015 12:13:45 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E3D5343344D; Thu, 17 Dec 2015 20:13:44 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id CA3FB433402; Thu, 17 Dec 2015 20:13:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1450383224; bh=sFVVnneszSlvLV6/pFK5v9nT9aJ3Cpr9Dm9KCO9tn5Y=; l=370; h=From:To:CC:Date:References:In-Reply-To:From; b=KaDIF1qZgyVT7Bio3XKkNGdsVr6bEtDdR8QlGkg3pSfe4PThIe2RkImHGtKbkfF+X i6cqW9OWftEfNMVBNVAC1U2wfFdoW3p96cQ6AngfIKS6Mj/3UcUtiloLUPOCh1NWQc Bb4JSmCYl6xjUMExE6XuIXDTXoYzP2weeMqg9XUE= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id C41F32046; Thu, 17 Dec 2015 20:13:44 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 17 Dec 2015 15:13:44 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Thu, 17 Dec 2015 15:13:44 -0500 From: "Salz, Rich" To: Eric Rescorla , Hugo Krawczyk Thread-Topic: [TLS] Explicit use of client and server random values Thread-Index: AQHROByg9ktfpH9240CbKaN0s5LaqZ7OZLCAgAAMjQCAAAOkAIABKceAgABQuQCAAAJhgP//rJSg Date: Thu, 17 Dec 2015 20:13:44 +0000 Message-ID: <3bb5d5d86e0741fcaffb706ea3ce905d@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56718D7A.4000302@cisco.com> <201512161530.06122.davemgarrett@gmail.com> <5671D454.6000506@cisco.com> <201512161628.02986.davemgarrett@gmail.com> <5672D12D.4010003@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: [172.19.42.251] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Explicit use of client and server random values X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2015 20:13:47 -0000 PiBEb2VzIGFueW9uZSAgZWxzZSBvYmplY3Qgb3IgZmVlbCBpdCBtYWtlcyBhbmFseXNpcyBoYXJk ZXI/IDopDQoNCk9oIHllYWgsIGxpa2UgYW55b25lJ3MgZ29ubmEgZGlzYWdyZWUgd2l0aCBIdWdv IHRoYXQgdGhpcyBtYWtlcyB0aGUgYW5hbHlzaXMgaGFyZGVyIDopDQoNClBhZ2luZyBXYXRzb24g Li4uIDopDQoNCi0tICANClNlbmlvciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dpZXMNCklN OiByaWNoc2FsekBqYWJiZXIuYXQgVHdpdHRlcjogUmljaFNhbHoNCg== From nobody Thu Dec 17 12:51:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91641B308A for ; Thu, 17 Dec 2015 12:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 yPFltcluxLZ9 for ; Thu, 17 Dec 2015 12:51:08 -0800 (PST) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id C360D1B307B for ; Thu, 17 Dec 2015 12:51:07 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id tBHKmIlS000625 for ; Thu, 17 Dec 2015 15:51:00 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: "tls@ietf.org" Thread-Topic: [TLS] Explicit use of client and server random values Thread-Index: AQHROByur80DTf9WZ0qomsmkJ7sRyp7OZLCAgAAMjQCAAAOkAIABKceAgABQuQCAAAJhgP//tYiA Date: Thu, 17 Dec 2015 20:44:49 +0000 Message-ID: References: <56718D7A.4000302@cisco.com> <201512161530.06122.davemgarrett@gmail.com> <5671D454.6000506@cisco.com> <201512161628.02986.davemgarrett@gmail.com> <5672D12D.4010003@cisco.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.5.8.151023 x-originating-ip: [172.25.177.51] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3533211883_554594" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2015-12-17_03:2015-12-17,2015-12-17,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-1511060000 definitions=main-1512170338 Archived-At: Subject: Re: [TLS] Explicit use of client and server random values X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2015 20:51:09 -0000 --B_3533211883_554594 Content-type: multipart/alternative; boundary="B_3533211883_562644" --B_3533211883_562644 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable > On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk w= rote: >> I have mentioned this in private conversations but let me say this here:= I >> would prefer that the nonces be explicitly concatenated to the handshake >> hash=E2=80=A6. > =20 > This change doesn't make implementation or specification significantly mo= re > difficult. Let=E2=80=99s do it. > Does anyone else object or feel it makes analysis harder? :) :-) --B_3533211883_562644 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk <hugo@ee.technio= n.ac.il> wrote:
I have mentioned this in private conversations but let me say this he= re: I would prefer that the nonces be explicitly concatenated to the handsha= ke hash….
 
This change doesn't make implementatio= n or specification significantly more difficult.

Let’s do it.

Does anyone  else object or feel it makes analysis ha= rder? :)

:-)

--B_3533211883_562644-- --B_3533211883_554594 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ0AYJKoZIhvcNAQcCoIIQwTCCEL0CAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKE5SxSwAAAABE8TANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1MDYxNTE2MjQzOVoXDTE2MDYxNDE2MjQzOVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC0tVFZOYvbDipiXfjylg0yIORem8AMZ4UQJ7EM2BI8 jKLj/h3RwH4w2DOMdepALLUqscSrpX6HPbo80M1O0cSSIYcYl8wQzDAMmvoD3HWbupwSXEPf eRtBo26jAvsDkOp46TPu40Pu61AkHx4vIgqU7XkofKhow18Ka/9ZkJ+oSnLK6Xy9+n8JiViO kTm2NjyF+CcpAobwZ3lBepHihvK3EilYR6V1EHQb+Y+2aWtexkFzBNXaN7i4Sdzq+LNSzCON DDDnRxA2c/B/p7MBDzocaigPxmKOHcE5eamxCgpJEUVCEALzeVZxcYURDJw68tZ90pJSLuw7 r6iigykQbRINAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUQzxm8xAhtcoaGyRStaMMhrmd7/Mw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAI8vbC+RZJEH0jhe5e9w F18xYCquDo5kxkoD83qYcVPVFYPnjuAvZ6o9ENa3F0GiAjFVm6HcUbm0zeWT6ZDYIrbh7GRM 4IO8pD9ziwvLIx8rvLvUhiBpsZvznVOWX1yGC0UkIKyiseAszczAYFVJonKB8jDRnxgFlPlo mFUaDtjL86cyp+pHc+ffUVyqMxacABFutJJ72HcK7tIf2gnh2qLdKToiTkDIWT+b1RrkQPSr Gr0YapAC5PgHd/RRY75FHdW/OEQOFimouKnBc5F2VsDJg0Ae9i0+nJPWwSpoXe0ISqIUMO47 Ei6ySfHR2mjymbByxmT5W3gAT3M2gyOd/XUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB 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 MIIE7TCCA9WgAwIBAgIKKHB6MgAAAAAtBzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE1MDEyMzE3NDkyOVoXDTE2MDEyMzE3NDkyOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDF+Rcs9hNO5hvlE0YeltqeXGUW1u3RVMG4/2ag6J2FgcsOJxOZ y/m+7FeYfCo3XYrNqx6/3IZmDSYln3JnxzPionDcbK2TJ9xAOoWlrUykAhgUl+PCO8ahDV5Y c0tmMzf5MXBrsub0nUyJeDkxOUY2Id58D1UVzzXh9Kvjc+ZCcBRFoViAgn7MznnuvK8Y5m7L or1oLWSxNNUyp98gC4EpdHLnA8yP1WqmNr0x+YssjJgEiIfZFqx8Gvv2OqtHaFGHh7Y6+WOW IZULMaAc9JJEq8ctns9mGIRldf2JMFcNsahQJDhgUspmP6c1Wz9OrUxsgwnGQ5feIq9c/4YZ YEZ/AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQUR0hebk4i6063YnpEEVXyQUyfSFMwDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBDAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBADim5zjTb/h3ea/66DNM6wSm i1Ti9F2f2/Are2a7a9E/IPXfleh39lVG7uTaneEJMSHzDltkB5k6DYMv/t28ntQm2jLI9adM wccDlKSR2uIDsiA7jodiTxbqL/aRi+WC4ybWWhXuzSbkMesayt5QAKpuKLAr7newfZaWx8zP nWU1nWZBbJR7cLKgUTaEiQu/NlCWIFJIC9yRhze+KR41vIa+7niQnUANjoYCCu32Z8xgxhK4 kQr5teUVUNDoCj02x781GFfwCknxpsWEm95OWM1iaXKCGJ8ciioulEzksZUrIHdImISaQVV+ Xdmbcd3OH6y8fNl1mZdXn8sxNJc+/g0xggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCChOUsUsAAAAARPEwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQx IgQgeQzwHV9x2h/p4P39BkyHvlGF9TyN8ZqzQ2XuUDxFwWEwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUxMjE3MjA0NDQzWjANBgkqhkiG9w0BAQEFAASC AQCaFn34oFmOaP89lNRjDGvRjvq/+Op8Ebp04UMy6pPXBMXEK4M5nCTO1H7CmMcCkDyViTJZ fpRQq5LZKn3O1xl03s9+n003yM9Ct80MVWNS86MxEVWHCM5foA4B4qoRzpzqD/o3rh9ORPyP o7NohKZipFZ6hBqQqvej1BPIh9VO11evEDOcRcwdL0Edx8RM4LRG7lnCH8e5n2a03E9YjkrQ YKlmcK5g6Bk+me6Kw2OGPeKs8t1hCRMrxoCN7HPoRnrPNfyGnecGNtdansdDyopUNEZ1vsvS 9AYx66QOqzsA2HjGkBMV2f5wxOFSHDDP1eCng5EnGHw4YiQbYWfoB9h6 --B_3533211883_554594-- From nobody Thu Dec 17 14:33:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532051A8A1C for ; Thu, 17 Dec 2015 14:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.556 X-Spam-Level: * X-Spam-Status: No, score=1.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, 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 0h3IZxaX9yDa for ; Thu, 17 Dec 2015 14:33:13 -0800 (PST) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFEB01A1A66 for ; Thu, 17 Dec 2015 14:33:13 -0800 (PST) Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id A1FEFF210A; Thu, 17 Dec 2015 14:29:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1450391342; bh=tqniVZ5ft0IrO0rF3ZE/vYL3P0M3mmPtGSocYtjdxrI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=kM3zeFVuqm2IZzJrg8q/0O6sQUhXSyUPDy34l+XdR1rRPile6lJHMxLGWNoMwA0CD I06s2M1hi6nRDtKmO9cwO9ZYs7Z5Hc0lLN00wBDxoma7qTV8NFOF0H+CSU6c5+uy/W QceFnj00DMLQ1hO9gFjEJDh2Yum1mjDvOE7AHzOo= Content-Type: multipart/alternative; boundary="Apple-Mail=_1E11E9BB-990F-41EE-96B4-AF4275D3DC40" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Mike Hamburg In-Reply-To: Date: Thu, 17 Dec 2015 14:33:11 -0800 Message-Id: References: <56718D7A.4000302@cisco.com> <201512161530.06122.davemgarrett@gmail.com> <5671D454.6000506@cisco.com> <201512161628.02986.davemgarrett@gmail.com> <5672D12D.4010003@cisco.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Explicit use of client and server random values X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2015 22:33:15 -0000 --Apple-Mail=_1E11E9BB-990F-41EE-96B4-AF4275D3DC40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 17, 2015, at 12:11 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk > wrote: > I have mentioned this in private conversations but let me say this = here: I would prefer that the nonces be explicitly concatenated to the = handshake hash. That is,=20 >=20 > handshake_hash =3D Hash( > client random || > server random || > Hash(handshake_messages) || > Hash(configuration) || > ) >=20 > The reason is that nonces are essential for freshness and session = uniqueness and I want to see them explicitly included in the = signed/mac-ed/KDF-ed information. I can envision a future variant/mode = of the protocol where parties do not transmit nonces but have a = synchronized state that they advance separately and use as nonces (e.g., = for key refreshing) - in such case the nonces would not be included in = the handshake-hash computation. >=20 > So while the redundancy of having them twice in the handshake_hash = calculation may be annoying, this adds robustness to the security (and = analysis) of the protocol. > =20 > This change doesn't make implementation or specification significantly = more difficult. > Does anyone else object or feel it makes analysis harder? :) >=20 > -Ekr While I haven=E2=80=99t been following TLS 1.3 development all that = closely, I will question this request. TLS is annoying to implement and analyze in part because it hashes = more-or-less arbitrary parts of the handshake messages together, in = arbitrary order, at arbitrary times. Removal of all the explicit = hashing of client/server random in TLS 1.3 makes it clearer what=E2=80=99s= going on, and makes implementations simpler. Some of the crypto = operations still feel pretty arbitrary (particularly Finished), but = things seem to be improving overall. In this context, it feels like = adding client random and server random back to the hash is a regression. =46rom an analysis point of view, the client and server random are = parseable from Hash(handshake messages) because they are concatenated = with framing information. But here, they are concatenated without = framing information. So I don=E2=80=99t understand Hugo=E2=80=99s = contention that the old scheme leads to trouble if the nonce changes = sizes in a later version, and that the new scheme does not. It seems to = me that the reverse is more likely to be true. Cheers, =E2=80=94 Mike= --Apple-Mail=_1E11E9BB-990F-41EE-96B4-AF4275D3DC40 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


On = Dec 17, 2015, at 12:11 PM, Eric Rescorla <ekr@rtfm.com> = wrote:



On Thu, Dec 17, 2015 at 3:02 PM, = Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
I have mentioned this in private conversations but = let me say this here: I would prefer that the nonces be explicitly = concatenated to the handshake hash.  That is, 

handshake_hash =3D Hash(
               =
             client =
random            ||
                            server random            =
||
                            Hash(handshake_messages) =
||
           =
                 Hash(configuration)      ||
                           )

The reason is that nonces are essential for = freshness and session uniqueness and I want to see them explicitly = included in the signed/mac-ed/KDF-ed information. I can envision a = future variant/mode of the protocol where parties do not transmit nonces = but have a synchronized state that they advance separately and use as = nonces (e.g., for key refreshing) - in such case the nonces would not be = included in the handshake-hash computation.

So while the redundancy of having them twice in the = handshake_hash calculation may be annoying, this adds robustness to the = security (and analysis) of the = protocol.
 
This change doesn't make implementation or specification = significantly more difficult.
Does anyone =  else object or feel it makes analysis harder? :)

-Ekr

While I haven=E2=80=99t been following TLS 1.3 = development all that closely, I will question this = request.

TLS is annoying to = implement and analyze in part because it hashes more-or-less arbitrary = parts of the handshake messages together, in arbitrary order, at = arbitrary times.  Removal of all the explicit hashing of = client/server random in TLS 1.3 makes it clearer what=E2=80=99s going = on, and makes implementations simpler.  Some of the crypto = operations still feel pretty arbitrary (particularly Finished), but = things seem to be improving overall.  In this context, it feels = like adding client random and server random back to the hash is a = regression.

=46rom an analysis point = of view, the client and server random are parseable from Hash(handshake = messages) because they are concatenated with framing information. =  But here, they are concatenated without framing information. =  So I don=E2=80=99t understand Hugo=E2=80=99s contention that the = old scheme leads to trouble if the nonce changes sizes in a later = version, and that the new scheme does not.  It seems to me that the = reverse is more likely to be true.

Cheers,
=E2=80=94 = Mike
= --Apple-Mail=_1E11E9BB-990F-41EE-96B4-AF4275D3DC40-- From nobody Thu Dec 17 15:39:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF611B312D for ; Thu, 17 Dec 2015 15:39:23 -0800 (PST) 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 u0MUzV1UQ30n for ; Thu, 17 Dec 2015 15:39:22 -0800 (PST) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D85F1B3113 for ; Thu, 17 Dec 2015 15:39:22 -0800 (PST) Received: by mail-io0-x241.google.com with SMTP id f127so2878124ioa.0 for ; Thu, 17 Dec 2015 15:39:22 -0800 (PST) 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=vkDCm74rPrl35gFsUMwb/U46bowlI8WbhMVZoUSraoE=; b=ThbMNQt2xdVrbIwvENz/Qp9sVZb1QqOHNcAgFbiWYFydyWYIlhLNSm7E6Rql7p8kv4 NVGb6KG0U6aOobkVAC9O+N48KsIUIJDzF0BX5qIGw3ZYXW66RFqWnPMsXCcl6bbo9cFL ZpWfyMIRs1RjUXz+Wg78F5F4e1MBC0r6HDhCw2RrJMY9WVAS6LDTXl/3BG1wQ3MCMR2p GYeOv3gU8QeWeg7UsVzNz1pwckbUyhWDzxfF+gM4Ck9pyaVd381FCFHtRhbBgIqAGaAu TJqV9LUZY6AYBf3JJoFAiXFpaCBbflYoK8AXJvbLchNf9QIYYXKvQm+wimgaHhjf45Wg +Q4Q== MIME-Version: 1.0 X-Received: by 10.107.33.203 with SMTP id h194mr1124755ioh.108.1450395562024; Thu, 17 Dec 2015 15:39:22 -0800 (PST) Received: by 10.36.149.130 with HTTP; Thu, 17 Dec 2015 15:39:21 -0800 (PST) In-Reply-To: <5e85e3b1a1914ea8bbd5d985c321c119@AM3PR30MB049.064d.mgd.msft.net> References: <5e85e3b1a1914ea8bbd5d985c321c119@AM3PR30MB049.064d.mgd.msft.net> Date: Fri, 18 Dec 2015 10:39:21 +1100 Message-ID: From: Martin Thomson To: Cedric Fournet Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Antoine Delignat-Lavaud , Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] [tls13-spec] resetting the sequence number to zero for each record key. (#379) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2015 23:39:23 -0000 So the actual impact here is that an attacker who has compromised a key can introduce a gap. Aren't there other options available to such an attacker? Scarier options? On 18 December 2015 at 07:01, Cedric Fournet wrote: > > We propose to revert this change (that is, to reset the sequence > number each time a new key is installed, as in TLS 1.2). If the > chaining is still required for some other reason, one could instead > include the old sequence number in the new key derivation (or the new > key's additional data, but we believe this is no longer an option). Even with my question above, this seems reasonable to me. I'll note that chaining in the way you describe would require that the rekey message (the last message of the previous epoch) would need to be retransmitted in DTLS. That seems more brittle, but we probably want to retransmit anyway, since that would let use remove the explicit epoch from DTLS packets. From nobody Thu Dec 17 16:53:53 2015 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BBF1A8A64; Wed, 16 Dec 2015 13:10:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151216211036.30456.40906.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 13:10:36 -0800 Archived-At: X-Mailman-Approved-At: Thu, 17 Dec 2015 16:53:50 -0800 Cc: draft-ietf-tls-cached-info@ietf.org, tls-chairs@ietf.org, tls@ietf.org Subject: [TLS] Ben Campbell's No Objection on draft-ietf-tls-cached-info-20: (with COMMENT) 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: Wed, 16 Dec 2015 21:10:36 -0000 Ben Campbell has entered the following ballot position for draft-ietf-tls-cached-info-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -section 4, paragraph 4: It might be helpful to have a little more guidance to clients for multi-tenant server environments. For example, the fact that it might want to cache different certs from the same server in the first place. Also, when might it be reasonable to violate the RECOMMENDED? - 4.1: Should the reference for 7250 be normative? From nobody Thu Dec 17 16:53:54 2015 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 990CE1B2E79; Thu, 17 Dec 2015 06:58:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151217145835.20836.344.idtracker@ietfa.amsl.com> Date: Thu, 17 Dec 2015 06:58:35 -0800 Archived-At: X-Mailman-Approved-At: Thu, 17 Dec 2015 16:53:51 -0800 Cc: draft-ietf-tls-cached-info@ietf.org, tls-chairs@ietf.org, tls@ietf.org Subject: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-cached-info-20: (with COMMENT) 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: Thu, 17 Dec 2015 14:58:36 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-tls-cached-info-20: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a quick comment, sorry for asking this late and I won't hold up on it either, just want to raise the question without quite enough time to research it all. I see the SHA-256 truncation is just 32 bits. In other applications, about half is what is typically recommended. I know you are trying to cut on space, but will problems arise from this shorter value? From nobody Thu Dec 17 16:53:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDC41B2EB4; Thu, 17 Dec 2015 07:22:07 -0800 (PST) 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 vS163Zp-etdG; Thu, 17 Dec 2015 07:22:06 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21EC1B2EAC; Thu, 17 Dec 2015 07:22:05 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id p187so26190638wmp.0; Thu, 17 Dec 2015 07:22:05 -0800 (PST) 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=uQV2c9NYLEmGnaB0gnIhaI7zVtPYKtUSoDdVafbyVx8=; b=p0bjbtnDajgxugYcpt+08nU5FemHhuO9XNQT2XW9u9Yd1e+otWUAx0M+QsdQJiVi5M SLaq1EUdppuTgF+RDqRXM5s2su/8Y7MewGHQRiYS2yF1Fz8L8qHsgkPSbZMPmgGj+iIN PgVONCxSy6+HolbrZkaFTq0dKlwRqRTuwNMP7M6vafu4RQfmOWaw+K0OtXNOHwZypcDO Lvh5iDrP9TIkxySbjpjKBoQ5BVdWH//wP+p6L41od0gxulAZbWCdDcjJzK1iO8EDKgVJ R6yW7fYz9394hbR4vFYp3iMGsmwGiYeiflkW9Zt2+stMpYpBDykayYLhfW1YHewkpBLj flOw== MIME-Version: 1.0 X-Received: by 10.28.68.133 with SMTP id r127mr4777505wma.71.1450365724140; Thu, 17 Dec 2015 07:22:04 -0800 (PST) Received: by 10.28.52.130 with HTTP; Thu, 17 Dec 2015 07:22:03 -0800 (PST) In-Reply-To: <5672D03A.8050609@cs.tcd.ie> References: <20151217145835.20836.344.idtracker@ietfa.amsl.com> <5672D03A.8050609@cs.tcd.ie> Date: Thu, 17 Dec 2015 10:22:04 -0500 Message-ID: From: Kathleen Moriarty To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Thu, 17 Dec 2015 16:53:51 -0800 Cc: draft-ietf-tls-cached-info@ietf.org, The IESG , tls@ietf.org, tls-chairs@ietf.org Subject: Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-cached-info-20: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Dec 2015 15:22:07 -0000 On Thu, Dec 17, 2015 at 10:09 AM, Stephen Farrell wrote: > > > On 17/12/15 14:58, Kathleen Moriarty wrote: >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-tls-cached-info-20: Yes >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Just a quick comment, sorry for asking this late and I won't hold up on >> it either, just want to raise the question without quite enough time to >> research it all. >> >> I see the SHA-256 truncation is just 32 bits. In other applications, >> about half is what is typically recommended. I know you are trying to >> cut on space, but will problems arise from this shorter value? > > Nah, I think this one's ok. IIUC, the result of a collision is > just a handshake fail, and then presumably recovery when they > ditch the cached stuff. Section 5 describes this. OK, no hold up on it, there just wasn't an explanation in the draft as to why 32 bits was enough in section 5 (or any other). Thanks, Kathleen > > S. > > >> >> -- Best regards, Kathleen From nobody Thu Dec 17 21:40:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8D71B3351 for ; Thu, 17 Dec 2015 21:40:28 -0800 (PST) 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 UL6HgRHPdXJL for ; Thu, 17 Dec 2015 21:40:26 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD39F1A8749 for ; Thu, 17 Dec 2015 21:40:25 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id l133so65530841lfd.2 for ; Thu, 17 Dec 2015 21:40:25 -0800 (PST) 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=C4+P/frq/dw/8xFJuIH7+tJdbHr3OhnwrW5Ev2rsAww=; b=f6yhcYeIT07IjUj/0gNMSp8eTnKaIMx9J/SQaLf9CIIDyrIkEj/PClommTafMLMKll 7GjsKGoPJnkLwpAd1YX6gd5bjxNeQQ5UNA3RGE1GmX61b/qcx51QvXgTq3o7VB0N5tBl Dy2K6p/rL/isSa3hLufJYUNHzs7bdSd7NKD7NnJg+M971gg7+07ozC9GUaBd7N72NoHx JL8K00N9gAByibqlA3D87VRPxAmXtfH6uJIvkqIZEAAU3vVl+FGuPMvliTCf+yS/q2zZ IivUGuYyRw4SzMWhz687hpdC+Cz6olKV5FXg8bNKZlaeX3C2+kVK/d6hgYWl5bwFOYXA q/gw== X-Received: by 10.25.153.144 with SMTP id b138mr444602lfe.167.1450417224060; Thu, 17 Dec 2015 21:40:24 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.168.210 with HTTP; Thu, 17 Dec 2015 21:39:54 -0800 (PST) In-Reply-To: References: <56718D7A.4000302@cisco.com> <201512161530.06122.davemgarrett@gmail.com> <5671D454.6000506@cisco.com> <201512161628.02986.davemgarrett@gmail.com> <5672D12D.4010003@cisco.com> From: Hugo Krawczyk Date: Fri, 18 Dec 2015 00:39:54 -0500 X-Google-Sender-Auth: YojmqLEyYO_dMRQmTWXdNtSHrB8 Message-ID: To: Mike Hamburg Content-Type: multipart/alternative; boundary=001a11401aec6a946f05272593f6 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Explicit use of client and server random values X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2015 05:40:28 -0000 --001a11401aec6a946f05272593f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 17, 2015 at 5:33 PM, Mike Hamburg wrote: > > > On Dec 17, 2015, at 12:11 PM, Eric Rescorla wrote: > > > > On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk > wrote: > >> I have mentioned this in private conversations but let me say this here: >> I would prefer that the nonces be explicitly concatenated to the handsha= ke >> hash. That is, >> >> handshake_hash =3D Hash( >> >> client random || >> >> server random || >> >> Hash(handshake_messages) || >> >> Hash(configuration) || ) >> >> >> The reason is that nonces are essential for freshness and session >> uniqueness and I want to see them explicitly included in the >> signed/mac-ed/KDF-ed information. I can envision a future variant/mode o= f >> the protocol where parties do not transmit nonces but have a synchronize= d >> state that they advance separately and use as nonces (e.g., for key >> refreshing) - in such case the nonces would not be included in the >> handshake-hash computation. >> >> So while the redundancy of having them twice in the handshake_hash >> calculation may be annoying, this adds robustness to the security (and >> analysis) of the protocol. >> > > This change doesn't make implementation or specification significantly > more difficult. > Does anyone else object or feel it makes analysis harder? :) > > -Ekr > > > While I haven=E2=80=99t been following TLS 1.3 development all that close= ly, I > will question this request. > > TLS is annoying to implement and analyze in part because it hashes > more-or-less arbitrary parts of the handshake messages together, in > arbitrary order, at arbitrary times. Removal of all the explicit hashing > of client/server random in TLS 1.3 makes it clearer what=E2=80=99s going = on, and > makes implementations simpler. > =E2=80=8BHow does removal of explicit hashing of the nonces make things cle= arer? What are the things that are made clearer? =E2=80=8B > Some of the crypto operations still feel pretty arbitrary (particularly > Finished), but things seem to be improving overall. In this context, it > feels like > =E2=80=8B=E2=80=8B > adding client random and server random back to the hash is a regression. > =E2=80=8BWhat do you mean by =E2=80=8B =E2=80=8B" =E2=80=8B adding client random and server random back to the hash is a regression =E2=80=8B"? Why "back"? Were they removed? What's the regression? You are probably not suggesting to omit them, right? Are you worried about the redundancy of being hashed twice? Is it a security issue or an implementation issue? =E2=80=8B .=E2=80=8B > > From an analysis point of view, the client and server random are parseabl= e > from Hash(handshake messages) because they are concatenated with framing > information. > =E2=80=8BThey are parseable, but I am not sure they are *uniquely* parseabl= e - a fixed location in the stream does make them uniquely parseable. =E2=80=8B > But here, they are concatenated without framing information. > =E2=80=8BThe nonces are the main framing information - they are the (honest parties') unique identifier of the handshake. =E2=80=8B > So I don=E2=80=99t understand Hugo=E2=80=99s contention that the old sche= me leads to > trouble if the nonce changes sizes in a later version, and that the new > scheme does not. It seems to me that the reverse is more likely to be tr= ue. > =E2=80=8BI'm clearly not following your argument. =E2=80=8BHugo =E2=80=8B > > Cheers, > =E2=80=94 Mike > --001a11401aec6a946f05272593f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Dec 17, 2015 at 5:33 PM, Mike Hamburg <mike@shif= tleft.org> wrote:


On Dec 17, 2015, at 12:11 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Th= u, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk=C2=A0<hugo@ee.= technion.ac.il>=C2=A0wrote:
=
I have mentioned this in private conversations but let me say this here= : I would prefer that the nonces be explicitly concatenated to the handshak= e hash.=C2=A0 That is,=C2=A0

handshake_hash =3D Hash(
                            =
client random            ||
                            server random            ||
<=
pre style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px">                            Hash(handshake_mess=
ages) ||
= Hash(configuration) || )

The reason is that nonces are essen= tial for freshness and session uniqueness and I want to see them explicitly= included in the signed/mac-ed/KDF-ed information. I can envision a future = variant/mode of the protocol where parties do not transmit nonces but have = a synchronized state that they advance separately and use as nonces (e.g., = for key refreshing) - in such case the nonces would not be included in the = handshake-hash computation.

So while the re= dundancy of having them twice in the handshake_hash calculation may be anno= ying, this adds robustness to the security (and analysis) of the protocol.<= /div>
=C2=A0
This change doesn't= make implementation or specification significantly more difficult.
Does anyone =C2=A0else object or feel it makes analysis harder? :)
=

-Ekr

While I haven=E2=80=99t been following TLS 1.3 development al= l that closely, I will question this request.

TLS = is annoying to implement and analyze in part because it hashes more-or-less= arbitrary parts of the handshake messages together, in arbitrary order, at= arbitrary times.=C2=A0 Removal of all the explicit hashing of client/serve= r random in TLS 1.3 makes it clearer what=E2=80=99s going on, and makes imp= lementations simpler.

=E2=80=8BHow does removal of explicit hashing of the nonc= es make things clearer? What are the things that are made clearer?

=E2=80=8B
=C2=A0
=C2=A0Some of the crypto operations still feel pretty arbit= rary (particularly Finished), but things seem to be improving overall.=C2= =A0 In this context, it feels like
=E2=80=8B=E2=80= =8B
adding client random and server random back to the hash is a regr= ession.

=E2=80=8BWhat do you mean by =E2=80=8B
=C2=A0
=E2=80=8B"
=E2=80=8B
=C2=A0adding client rando= m and server random back to the hash is a regression
=E2=80=8B"?
Why "bac= k"? Were they removed? What's the regression?
You are probably not suggesting to omit them, right? = Are you worried about the redundancy of being hashed twice? Is it a securit= y issue or an implementation issue?
=E2=80=8B
.=E2=80=8B=

=
From an analysis point of view, the client and server random are= parseable from Hash(handshake messages) because they are concatenated with= framing information.

=E2=80=8BThey are parseable, but I am not sure they are *u= niquely* parseable - a fixed location in the stream does make them uniquely= parseable.

=E2=80= =8B
=C2=A0
<= div> =C2=A0But here, they are concatenated without framing information. =C2= =A0

= =E2=80=8BThe nonces are the main framing information - they are the (honest= parties') unique identifier of the handshake.

=E2=80=8B
=C2=A0
So I don=E2=80=99t understand Hu= go=E2=80=99s contention that the old scheme leads to trouble if the nonce c= hanges sizes in a later version, and that the new scheme does not.=C2=A0 It= seems to me that the reverse is more likely to be true.

=E2=80=8BI'm clearl= y not following your argument.

=E2=80= =8BHugo
=E2=80=8B

Cheers,
=E2=80=94 Mike
=

--001a11401aec6a946f05272593f6-- From nobody Fri Dec 18 07:48:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E011B36B2 for ; Fri, 18 Dec 2015 07:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_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 5ZdJw_57ixfm for ; Fri, 18 Dec 2015 07:48:01 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0135.outbound.protection.outlook.com [65.55.169.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 645D31B36B1 for ; Fri, 18 Dec 2015 07:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kiJuZzBFUvJEGYGhDyFyEhfDg5B0sPfQcw777B/9v9Q=; b=JkqQWbdlxWzyxkg0s7nh89ugcYeA/61jKfG8JzDfgsbOQTZakc45KTu+By/PZp3Fr4xsywFxX3hnIFwI11fy9NhJfzUDsnold1kCsXSoOlXdzet1Q77yMIoqnJScUuTPzZWNCrsHu6da9hoGrEhJOz3NPl6ol5fkc3IvZnZs3lI= Received: from DM2PR03CA0047.namprd03.prod.outlook.com (10.141.96.46) by BLUPR03MB519.namprd03.prod.outlook.com (10.141.80.144) with Microsoft SMTP Server (TLS) id 15.1.355.16; Fri, 18 Dec 2015 15:47:57 +0000 Received: from BY2FFO11FD018.protection.gbl (2a01:111:f400:7c0c::142) by DM2PR03CA0047.outlook.office365.com (2a01:111:e400:2428::46) with Microsoft SMTP Server (TLS) id 15.1.361.13 via Frontend Transport; Fri, 18 Dec 2015 15:47:57 +0000 Authentication-Results: spf=pass (sender IP is 206.191.249.68) smtp.mailfrom=microsoft.com; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=pass action=none header.from=microsoft.com; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.249.68 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.249.68; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.249.68) by BY2FFO11FD018.mail.protection.outlook.com (10.1.14.106) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Fri, 18 Dec 2015 15:47:56 +0000 Received: from AM3PR30MB049.064d.mgd.msft.net (141.251.48.82) by AM3PR30MB051.064d.mgd.msft.net (141.251.48.84) with Microsoft SMTP Server (TLS) id 15.1.365.9; Fri, 18 Dec 2015 15:47:53 +0000 Received: from AM3PR30MB049.064d.mgd.msft.net ([141.251.48.82]) by AM3PR30MB049.064d.mgd.msft.net ([141.251.48.82]) with mapi id 15.01.0337.009; Fri, 18 Dec 2015 15:47:53 +0000 From: Cedric Fournet To: Martin Thomson Thread-Topic: [TLS] [tls13-spec] resetting the sequence number to zero for each record key. (#379) Thread-Index: AQHROSQrWxcUcSg40EiXRu2VKguhkp7QgGUw Date: Fri, 18 Dec 2015 15:47:53 +0000 Message-ID: <7327a9142c2c41f39028d8882be8ae45@AM3PR30MB049.064d.mgd.msft.net> References: <5e85e3b1a1914ea8bbd5d985c321c119@AM3PR30MB049.064d.mgd.msft.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.251.48.69] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD018; 1:w9S/nVBuYrsGjWEbrytigxM5zFKF120THfYC8yzHRUD0mfqrKkOU1hCcV33NHThMCD1+03ttbo0Tb5Ykb4BEPiRdD+DrZ781imAA1qHfppmVJicXt17yJVbi32+VyJ6mK0y11rNQlZsHym6MJO8vPe7E6KmmAF8t9FXOrGQ/mI5kRWJ37Obj3zxpd41sL4DI4XLJ0EojDW3Z21gvU5Ov5ZxG6EEKcf/WK5hYPpv90JHwOQskQzNldFCaSbxSrtD7ZD2vfj6BYwL+vPv9afFDQa0BgWONe7Z46LFkDWyht6cDQP1wWV1DCmsw/QkwI1Ibc34/rAFygWSBz7EG4faISg== X-Forefront-Antispam-Report: CIP:206.191.249.68; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(24454002)(199003)(13464003)(52314003)(189002)(106466001)(2950100001)(54356999)(6806005)(92566002)(97736004)(106116001)(69596002)(102836003)(19580395003)(110136002)(108616004)(50466002)(5004730100002)(11100500001)(5001960100002)(189998001)(2900100001)(19580405001)(5008740100001)(24736003)(23676002)(586003)(1096002)(66066001)(5003600100002)(81156007)(26826002)(3846002)(86362001)(47776003)(6116002)(50986999)(76176999)(33646002)(10290500002)(1220700001)(16796002)(10400500002)(86612001)(87936001)(10090500001)(5005710100001)(86146001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB519; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB519; 2:/8KltD2oATQCvaGHM5MKz7mzBOZItGkmu4omfJAMT0LIpB2l6lJrs5b/XKcrtj3w+WjqGYZ/i67Y1p+IX8shi5k23gWqNotSP5uBa28t2meFBVUedQsEfysdmzC8bL5ZQLShN/QFl2bQ+sLbv8JZSA==; 3:7lMp7tzuoEFumfLvG6mPIckkjrJJ/b+xpdJk+HfB6DRCcGFxrsSGvNtW0WYwRMN1SEiVdP2QTy6Bmt9WcVlaVvMT5mDfzmZpWTYZbkXr06af7li0YG508PTSfUWnAZ0qEl+4+Hnyy9EG8JMUbrcHOrYm2z0IDK5bUOtWJFD14iyuWAhYuuLlSVcNKtrT/P6n8biJQfnpIqgvpE68c7B7I3+sv/hp6Mk5Yyz/9HJf3LdTXTXsiRt4HVYGZxd1Jn/puv2gBQdARNm1N3G/Hj97jg==; 25:Xe2N5FeC6u+Lax9njKWMHgPF8ffaUmDdlLwSHXgryeWphhV6hQ5BMz6iQ5i3b2aXRTxEK39oTjb70K2z9PgEpgGX2MYqWBechssA+b1ZIY6KGoHQ3X8PISC9FNzCJ4COS/jLvgsSPNEIdMCCE8dipxHK+gtx3crrbIm2p5msxzLGQThITnainLKxsHHIUrekbKBgQmaAwrukyCtSq2mXYf3MnDqXGpkgOeQ+kcZYWoCrOrMfXP3lKCZl9M2mJ0TWu14OYLJWyKQKLie0rNytTxbAyTchAcBHhFeSAMhFeIw= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:BLUPR03MB519; X-O365EOP-Header: O365_EOP: Allow for Unauthenticated Relay X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB519; 20:DqtxsUB0v0+drc4nHweo3vkWhPNbl+CYpBQ+FroisviGOJ9PTlPJK9ym88hHoMLprQfbIYoYYa1tq+Fdhjqyt+axuQjtpOZFBhw6/Ea+YN9y3yElL3qhU5LVfQW4MCARyA3kC2t8EmZ8imLzldwWO1icCwpOznkO4/Z+WwEoRd5Eli7+0IBvRjf47FTQi69ZU/bbEKQnp8FPVbA2DOkBD2UArEsYU6bnjMpwe/Gf1a/v65lNacJcTnps9TnCe44lgaItsWzmTw/rnZFPW0iIv7ADIPBoK55KECMrd8hOFU9XFY5wgols4DzqwekbSRXEOM2s6hENwJEI4pz2vsua6hL+KuNqNQhCS9NJT+0i3PDHK10Y1hiXqtll0MZffckT0LMHx6D9wIhVLwWB9E03O5B3NB1Pqrdb1GC4+tzZbCYtcT9DciCy73/V2TtrsI2EurXZSk4m5pIysphiTNkavTIc5eyCuwAwv0ecjrhSDEGicpfoPCZxsmU9hdYBuxgD9qq9ZkhfwlZg2b+PvYoBfhBoDi8XjFduDvA537ofOBEf7f0Nlk+VAEgSCNKLYDsn4BOcb8JPCvOENFxAcjhF/YCczcPV6kIvqcNsxhCHRDo= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BLUPR03MB519; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB519; X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB519; 4:bIF/HgY6w9ufMfQhAHCbwBNYRwVCWiQgsPw1hBf5Dw7sCPD2/itCDIX08IUZSbkUL+aoaMSGPexmtkY4OpMlYhA/o4s10xsEF/cG97VXIWFvpHB7OfSX0ZekMzltFoS7e75DaW7y7r2Q9BGeEpNuv+CYeSLXiwKCcbr4CwliCE7EXb7NzDVOQ3fI+vCB15RqpXvdXFMJzU0qn/cIhunE5Zw7bG9SpgWxb8XfrO3bSKgqWTcg7qPo50llgwSRXNjBe0KdgFUv+yEgj/SkHtnCxJgkvVfEQX2Xu+VCHg61KgTaTowgV4+jYiQGvVoR9l44X6DQDBXRxWSkSj0c6wB4ZuuTjit8jCADEaFgoTlP1WMqL3HMls5MUrBEVRbLXFy5rTZZ+mJvk3JoqQpyxc/wPoNCVVsdwc/75parJeVimZnXdEFUMbaUR27vxC3qyZt3 X-Forefront-PRVS: 07943272E1 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjAzTUI1MTk7MjM6cHJyWHhMRENqMmNNR2dtUjNPdnlDbGVadENk?= =?utf-8?B?QUF2bmVaWkozRk54MzVtcm9IMmxvYTFxdlVhK3pkSlphVWNXemNzaEhkRlJ3?= =?utf-8?B?cXBnUko5eXRnamFRWmVNMGVwbDhpVTQwc09vS294cW11bllaWUtXQ3pZdWtK?= =?utf-8?B?RWJVTkhOdlhJMXpNZ2dZVWFTOGdaYWpoNXdmcXAxd2c2aFArYUQ1NzNnUHR6?= =?utf-8?B?TEhYT2NTRHZoeDdFSytrK0xhNUU1c3kvYkpBc0xNTExJT2I5RHA1dm9wdEFG?= =?utf-8?B?aUJLUkxyd3FSc2ZZS0VFWndJbUpUU3lNWjBVYkhpbHFVZytIUk9tNVB5Z0Z1?= =?utf-8?B?M01aKzZVSktFUWlzTEM0cjJTZmNPZGdWdmNybEhueHdOMDZSNUdOemUzdTdU?= =?utf-8?B?TTNncy9YN1VsNzd3aVNWQThFR2ZrWndLbDRCNFVZanp1dDM3ZHkwOSt3VHdp?= =?utf-8?B?M3M3NS9Udy9HaTdHOGQ4VG03bS9YM3VkelUwYWI3bmZNZmtRaU40c2RuSU5k?= =?utf-8?B?UytNRVloZnJ6N2RCU0JWNVI0cWttZWhUamFXdGVQTGl3cTgyYzQveTN0ZzNt?= =?utf-8?B?eXVaTzl6dkh0S2lLdVI2V2UyN3ZvejBtTG9EN3dTSlhzTVVrUGovVlN0VnJq?= =?utf-8?B?MW5pajVGdE14VzEwQTNRUHczTXhFdE5Lczl4RkxwMzdsa0dPU0ZBUUlpY0w1?= =?utf-8?B?ZmtJck50RzU4TUs0WGwrNFY1UlNqckpsY21nd202YW05L0E3SmEwYVhna2xG?= =?utf-8?B?WjZOdmllOGNkR1hPaXVBRTZnUWNVMUN3RG5BQ3pPbGtWNHloZWdpaXFaNUYy?= =?utf-8?B?ZTR6NVRmTzhNdDR4RzBkVlYwbFdlOXJValM4dVdWU1Y0L1BTUUkvNEIwU2Qw?= =?utf-8?B?K2NqR1VUbXcwUjVPNm9xOTNOTTcyZENwcitZTFNZekJGN0o0T1A0ditEVStC?= =?utf-8?B?aTZ1aVF0eFliVlBRZFlVNDhCVmllYVVnVnYwNEtuK3Rnc1I5a3lKRDFOZW8w?= =?utf-8?B?SXY0c1RTZGZxQmdFV0JvVnV3WXJpczR4NHFJS2lucEFHUCtKZmQ4UE95ak1o?= =?utf-8?B?QWczWWYyY3RuaC9RMElEM1pEZS9lYWkzaDFnWlMyQVpVQ1hCOTNKT3l0eFJk?= =?utf-8?B?TDFwYUhvVnpsNWtlaDZ2ZmUwOEI3ZUFmKzRkRU85ZDdyNzkyTUk1R1R2Y0FY?= =?utf-8?B?LzJ1K2Jqb08rRDB4UGQ5eDVUa3luYzBzWHhMOG1IeHdjWVU5NWU4YXZaaVNO?= =?utf-8?B?NytGNjJrb3ZZQTVDOHNsQXNpOXFJTHRBQUhlcWJDYjJSWUZ5N01raVkyZ0lK?= =?utf-8?B?NnR0emlTUnkrM2NXNEdoT0NYTUtmZVY2Y3kzL28yaUlyYVp5a2tyek4vcnQw?= =?utf-8?B?NGtrdUtIZGV5akEwVU95Z3lqYzgzc0JwWHVqckNjdTVUeHliTlRPblpVRlhz?= =?utf-8?B?alBMdmc0YTc4UVR2OXd0ZkJkcUdRYzREWTcrbjZ4WExJc250N28yTXZMNStI?= =?utf-8?B?SnZmeVdwTDJodS9oVTdxWXIwSDVoNEdxRk5YZkZEcklnRFdRZkNqL0RiTzlX?= =?utf-8?B?aVN6a2R2YXowVGtlVno0b29nbnBaUjFOdXlJc2lLemthay9Tb0V6b0lVbkxF?= =?utf-8?B?UmRLV2pSd3doVXkzSkQ5OExLTm9zZW1Fc1JDNS9rK2RGd25CWXdEb1JQUlNO?= =?utf-8?B?MmZTQmpmdkNrLzdXbjRyVk10Q3FQY2dYZHlNZDl3TmVFNU5iNXZQRjdQWXBH?= =?utf-8?B?U2FKY2FESWJORWtrTGNmRTB1bEZNTUYwVXArSFBHQ2NTRURDeFg2Rll1Risy?= =?utf-8?B?K0o4d3R5NlBqdEIxTHpJRncvMnRsWUFINjRYUU5TUmQvZz09?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB519; 5:iOOHSPhkMbl+lXYPW7KJb9G8JBru2NThVB51tKrkAzFm9cbev2J+CHfGy+tGwkfoWZbGod6NCSRBqbAyneDQmHJV4nh39hjhnXRj2zUBBFC/bO/WUZqnPvy5fq+QxScy5v4EUY33v9K8fJ499CZfdQ==; 24:nURgL6nkRNgI1ZVusFJqslVxqYsbVBsmipmm21Q3LSbiZL9sOU3DM92ZorJxGOUvJHEgNRmtjdfvXPoxp+LOdyneoecmwJCeHxQY63eFal8= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2015 15:47:56.3088 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.249.68]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB519 Archived-At: Cc: Antoine Delignat-Lavaud , Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] [tls13-spec] resetting the sequence number to zero for each record key. (#379) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2015 15:48:05 -0000 VGhlIHN1cnByaXNlIGlzIHRoYXQgYnJlYWtpbmcgb25lIGtleSBhbHNvIHlpZWxkcyB0aGUgYWJp bGl0eSB0byB0cnVuY2F0ZSB0cmFmZmljIHByb3RlY3RlZCB3aXRoIGFub3RoZXIga2V5LiBXZSBh Z3JlZSB0aGF0IHdlIGRvbid0IGhhdmUgYW55IHBhcnRpY3VsYXJseSBzY2FyeSB3YXkgdG8gZXhw bG9pdCBpdCBhZ2FpbnN0IHRoZSBjdXJyZW50IGRyYWZ0LCBidXQgd2UnZCBtdWNoIHByZWZlciBo YW5kc2hha2UgZW5jcnlwdGlvbiBub3QgdG8gZGVwZW5kIG9uIDBSVFQsIGFuZCBhcHBsaWNhdGlv biBkYXRhIHByb3RlY3Rpb24gbm90IHRvIGRlcGVuZCBvbiBoYW5kc2hha2UgZW5jcnlwdGlvbi4N Cg0KV2l0aCBvdXIgcHJvcG9zZWQgY2hhbmdlLCB0aGUgbWFpbiBwb2ludCB0byBrZWVwIGluIG1p bmQgaXMgdGhhdCwgYnkgZGVzaWduLCB0aGUgVExTIDEuMyByZWNvcmQgbGF5ZXIgZG9lcyBub3Qg cHJldmVudCBzdWZmaXggdHJ1bmNhdGlvbnMuIEluc3RlYWQsIFRMUyBwcmV2ZW50cyBwcmVmaXgg dHJ1bmNhdGlvbnMgYXQgdGhlIHByb3RvY29sIGxheWVyLCBieSBzZW5kaW5nIGFuIHVuYW1iaWd1 b3VzIGZpbmFsIG1lc3NhZ2Ugd2l0aCBlYWNoIHJlY29yZCBrZXk6ICBlbmRfb2ZfZWFybHlfZGF0 YTsgZmluaXNoZWQ7IGFuZCBjbG9zZV9ub3RpZnkuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNv bV0gDQpTZW50OiAxNyBEZWNlbWJlciAyMDE1IDIzOjM5DQpUbzogQ2VkcmljIEZvdXJuZXQgPGZv dXJuZXRAbWljcm9zb2Z0LmNvbT4NCkNjOiB0bHNAaWV0Zi5vcmc7IEFudG9pbmUgRGVsaWduYXQt TGF2YXVkIDxhbnRkbEBtaWNyb3NvZnQuY29tPjsgS2FydGhpa2V5YW4gQmhhcmdhdmFuIDxrYXJ0 aGlrLmJoYXJnYXZhbkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW1RMU10gW3RsczEzLXNwZWNd IHJlc2V0dGluZyB0aGUgc2VxdWVuY2UgbnVtYmVyIHRvIHplcm8gZm9yIGVhY2ggcmVjb3JkIGtl eS4gKCMzNzkpDQoNClNvIHRoZSBhY3R1YWwgaW1wYWN0IGhlcmUgaXMgdGhhdCBhbiBhdHRhY2tl ciB3aG8gaGFzIGNvbXByb21pc2VkIGEga2V5IGNhbiBpbnRyb2R1Y2UgYSBnYXAuICBBcmVuJ3Qg dGhlcmUgb3RoZXIgb3B0aW9ucyBhdmFpbGFibGUgdG8gc3VjaCBhbiBhdHRhY2tlcj8gIFNjYXJp ZXIgb3B0aW9ucz8NCg0KT24gMTggRGVjZW1iZXIgMjAxNSBhdCAwNzowMSwgQ2VkcmljIEZvdXJu ZXQgPGZvdXJuZXRAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+DQo+IFdlIHByb3Bvc2UgdG8gcmV2 ZXJ0IHRoaXMgY2hhbmdlICh0aGF0IGlzLCB0byByZXNldCB0aGUgc2VxdWVuY2UgDQo+IG51bWJl ciBlYWNoIHRpbWUgYSBuZXcga2V5IGlzIGluc3RhbGxlZCwgYXMgaW4gVExTIDEuMikuIElmIHRo ZSANCj4gY2hhaW5pbmcgaXMgc3RpbGwgcmVxdWlyZWQgZm9yIHNvbWUgb3RoZXIgcmVhc29uLCBv bmUgY291bGQgaW5zdGVhZCANCj4gaW5jbHVkZSB0aGUgb2xkIHNlcXVlbmNlIG51bWJlciBpbiB0 aGUgbmV3IGtleSBkZXJpdmF0aW9uIChvciB0aGUgbmV3IA0KPiBrZXkncyBhZGRpdGlvbmFsIGRh dGEsIGJ1dCB3ZSBiZWxpZXZlIHRoaXMgaXMgbm8gbG9uZ2VyIGFuIG9wdGlvbikuDQoNCkV2ZW4g d2l0aCBteSBxdWVzdGlvbiBhYm92ZSwgdGhpcyBzZWVtcyByZWFzb25hYmxlIHRvIG1lLiAgSSds bCBub3RlIHRoYXQgY2hhaW5pbmcgaW4gdGhlIHdheSB5b3UgZGVzY3JpYmUgd291bGQgcmVxdWly ZSB0aGF0IHRoZSByZWtleSBtZXNzYWdlICh0aGUgbGFzdCBtZXNzYWdlIG9mIHRoZSBwcmV2aW91 cyBlcG9jaCkgd291bGQgbmVlZCB0byBiZSByZXRyYW5zbWl0dGVkIGluIERUTFMuICBUaGF0IHNl ZW1zIG1vcmUgYnJpdHRsZSwgYnV0IHdlIHByb2JhYmx5IHdhbnQgdG8gcmV0cmFuc21pdCBhbnl3 YXksIHNpbmNlIHRoYXQgd291bGQgbGV0IHVzZSByZW1vdmUgdGhlIGV4cGxpY2l0IGVwb2NoIGZy b20gRFRMUyBwYWNrZXRzLg0K From nobody Fri Dec 18 07:50:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9571B3424 for ; Fri, 18 Dec 2015 07:50:00 -0800 (PST) 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 NwBD-PX70_4X for ; Fri, 18 Dec 2015 07:49:57 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01FC81B36A5 for ; Fri, 18 Dec 2015 07:49:56 -0800 (PST) Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB122.namprd09.prod.outlook.com (10.255.200.156) with Microsoft SMTP Server (TLS) id 15.1.355.16; Fri, 18 Dec 2015 15:49:37 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0355.012; Fri, 18 Dec 2015 15:49:37 +0000 From: "Dang, Quynh" To: "tls@ietf.org" Thread-Topic: [TLS] Data volume limits Thread-Index: AQHRN326ECu0fHUB6EGja4Q2uc5EIJ7NTTAHgAAqpwCAAJE6gIAAzzaAgAAu9YCAAc3M+g== Date: Fri, 18 Dec 2015 15:49:36 +0000 Message-ID: References: <87twnibx5p.fsf@latte.josefsson.org> <1450340361.7118.5.camel@redhat.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-originating-ip: [129.6.105.150] x-microsoft-exchange-diagnostics: 1; BN1PR09MB122; 5:e27RvFHGlTL2C9Ssz1Wptm4CzKl9PiVahoy8ey9A0kRl6+mzDohk2/HQXlYV53lWrgRm+IGVD248TuyGGkYCKXKSQqlB1TBguKSK6Ksm9oepzD/tPq7bIRBLuhZxQjwveEvF/YcLfR+xLCy5sHszhg==; 24:Qi2BigFIJME+l4vUQhVNZeQaeOkQJgBMbvBlA6GjjEd/IsBkRsPbG7iX07YtSXBh7k5/gs/WsQAGHJ6pHGBIxW8TAAyVaXg6IJuFSL8KKQY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB122; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN1PR09MB122; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB122; x-forefront-prvs: 07943272E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(189002)(377424004)(377454003)(199003)(19580395003)(15975445007)(2900100001)(107886002)(3846002)(5003600100002)(66066001)(6116002)(87936001)(586003)(189998001)(1220700001)(5008740100001)(450100001)(1096002)(5001960100002)(110136002)(97736004)(1730700002)(33656002)(2501003)(4001150100001)(81156007)(5002640100001)(102836003)(2950100001)(76176999)(10400500002)(5004730100002)(77096005)(92566002)(50986999)(86362001)(40100003)(54356999)(106356001)(76576001)(122556002)(106116001)(105586002)(2351001)(11100500001)(74316001)(93886004)(19580405001)(99286002)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB122; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2015 15:49:36.6087 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB122 Archived-At: Subject: Re: [TLS] Data volume 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, 18 Dec 2015 15:50:00 -0000 The collision probability of ciphertext blocks also depends on the size of = the plaintext (record size in a TLS implementation) in each call of the GC= M encryption function. Let's call each plaintext to be 2^x 128-bit blocks= . TLS 1.3 uses 96-bit IV.=20 If someone wants the collision probability below 1/2^y such as 1/2^24 or 1/= 2^32 (2^32 =3D 4,294,967,296 and 2^24 =3D 16,777,216 ), the total number of= plaintext blocks under a given key must be 2^((96 + x - y)/2) or lower. =20 So, 2^((96 + x - y)/2) 128-bit blocks are the limit to achieve IND-* with = GCM.=20 If someone does not need IND-* property, the above restriction is not neede= d. Quynh.=20 ________________________________________ From: TLS on behalf of Yoav Nir Sent: Thursday, December 17, 2015 6:07 AM To: Nikos Mavrogiannopoulos Cc: tls@ietf.org; Simon Josefsson Subject: Re: [TLS] Data volume limits > On 17 Dec 2015, at 10:19 AM, Nikos Mavrogiannopoulos wr= ote: > > On Wed, 2015-12-16 at 09:57 -1000, Brian Smith wrote: > >> Therefore, I think we shouldn't add the rekeying mechanism as it is >> unnecessary and it adds too much complexity. > > Any arbitrary limit for a TLS connection is almost guaranteed to cause > problems in the future. We cannot predict whether 2^x should be > sufficient for everyone, and I'm pretty sure this will prove to be a > terrible mistake. TLS is already being used for VPNs and transferring > larger amounts of data in long lived connections is a reality even > today. The rekey today happens using the reauthentication mechanism, > which has very complex semantics. Converting these to a simpler and > predictable rekey mechanism would be an improvement. Agreed. The alternative to having a rekey mechanism is to push the complexi= ty to the application protocol, requiring it to be able to use more than on= e connection to transfer all the data, which may require some sort of sessi= on layer to maintain state between connections. So unless we can guarantee or require that every algorithm we are going to = use is good for some ridiculous amount of data (2^64 bytes may be enough), = we need rekeying. Yoav _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls= From nobody Fri Dec 18 12:55:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806541B306F for ; Fri, 18 Dec 2015 12:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.556 X-Spam-Level: * X-Spam-Status: No, score=1.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, 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 qbj0lCSEjTDq for ; Fri, 18 Dec 2015 12:55:47 -0800 (PST) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 136251B2BDF for ; Fri, 18 Dec 2015 12:55:47 -0800 (PST) Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id A79093A9C5; Fri, 18 Dec 2015 12:51:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1450471892; bh=ey9wVzaFTLYews146mDSB/k1ZQCe27LWuRnjT8aTYAM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=kiyYPXJVYV1sEY6f+3j3SV80bKJeJLP/vtbJFsiDj5nVnBKTX5Yu/KZ0/faR/qKYI HwCi/2/+f1VqzNQVM003MnrwJy0Ve27sOkJAS9GYXGOwvhjLwehuGi14sRwGuDbneY yjTiYWnSZa+J3i3tJjVsG8Vm5gqZ32aZf03HYWlQ= Content-Type: multipart/alternative; boundary="Apple-Mail=_91EA2F86-008F-4EB7-8943-65F33B2BB420" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Mike Hamburg In-Reply-To: Date: Fri, 18 Dec 2015 12:55:45 -0800 Message-Id: <518C2E3A-D72E-443D-80CF-C27E085292EC@shiftleft.org> References: <56718D7A.4000302@cisco.com> <201512161530.06122.davemgarrett@gmail.com> <5671D454.6000506@cisco.com> <201512161628.02986.davemgarrett@gmail.com> <5672D12D.4010003@cisco.com> To: Hugo Krawczyk X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Explicit use of client and server random values X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2015 20:55:49 -0000 --Apple-Mail=_91EA2F86-008F-4EB7-8943-65F33B2BB420 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Whoops, big-R to reply all... > On Dec 17, 2015, at 9:39 PM, Hugo Krawczyk = wrote: >=20 >=20 > On Thu, Dec 17, 2015 at 5:33 PM, Mike Hamburg > wrote: >=20 >=20 >> On Dec 17, 2015, at 12:11 PM, Eric Rescorla > wrote: >>=20 >>=20 >>=20 >> On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk = > wrote: >> I have mentioned this in private conversations but let me say this = here: I would prefer that the nonces be explicitly concatenated to the = handshake hash. That is,=20 >>=20 >> handshake_hash =3D Hash( >> client random || >> server random || >> Hash(handshake_messages) || >> Hash(configuration) || >> ) >>=20 >> The reason is that nonces are essential for freshness and session = uniqueness and I want to see them explicitly included in the = signed/mac-ed/KDF-ed information. I can envision a future variant/mode = of the protocol where parties do not transmit nonces but have a = synchronized state that they advance separately and use as nonces (e.g., = for key refreshing) - in such case the nonces would not be included in = the handshake-hash computation. >>=20 >> So while the redundancy of having them twice in the handshake_hash = calculation may be annoying, this adds robustness to the security (and = analysis) of the protocol. >> =20 >> This change doesn't make implementation or specification = significantly more difficult. >> Does anyone else object or feel it makes analysis harder? :) >>=20 >> -Ekr >=20 > While I haven=E2=80=99t been following TLS 1.3 development all that = closely, I will question this request. >=20 > TLS is annoying to implement and analyze in part because it hashes = more-or-less arbitrary parts of the handshake messages together, in = arbitrary order, at arbitrary times. Removal of all the explicit = hashing of client/server random in TLS 1.3 makes it clearer what=E2=80=99s= going on, and makes implementations simpler.=20 >=20 > =E2=80=8BHow does removal of explicit hashing of the nonces make = things clearer? What are the things that are made clearer? >=20 > =E2=80=8B=20 > Some of the crypto operations still feel pretty arbitrary = (particularly Finished), but things seem to be improving overall. In = this context, it feels like=E2=80=8B=E2=80=8B adding client random and = server random back to the hash is a regression. >=20 > =E2=80=8BWhat do you mean by =E2=80=8B =E2=80=8B"=E2=80=8B adding = client random and server random back to the hash is a regression=E2=80=8B"= ? > Why "back"? Were they removed? What's the regression? > You are probably not suggesting to omit them, right? Are you worried = about the redundancy of being hashed twice? Is it a security issue or an = implementation issue? > =E2=80=8B.=E2=80=8B >=20 > =46rom an analysis point of view, the client and server random are = parseable from Hash(handshake messages) because they are concatenated = with framing information. >=20 > =E2=80=8BThey are parseable, but I am not sure they are *uniquely* = parseable - a fixed location in the stream does make them uniquely = parseable. >=20 > =E2=80=8B=20 > But here, they are concatenated without framing information. =20 >=20 > =E2=80=8BThe nonces are the main framing information - they are the = (honest parties') unique identifier of the handshake. >=20 > =E2=80=8B=20 > So I don=E2=80=99t understand Hugo=E2=80=99s contention that the old = scheme leads to trouble if the nonce changes sizes in a later version, = and that the new scheme does not. It seems to me that the reverse is = more likely to be true. >=20 > =E2=80=8BI'm clearly not following your argument. >=20 > =E2=80=8BHugo > =E2=80=8B >=20 > Cheers, > =E2=80=94 Mike Sorry Hugo, I misread the proposal as using the nonces and handshake = hash when signing, but not elsewhere. On rereading, it is still = entirely consistent, and isn=E2=80=99t being added =E2=80=9Cback=E2=80=9D = anywhere, except perhaps to some memory structure in the handshake code. = It also definitely isn=E2=80=99t a security problem, and it isn=E2=80=99t= as annoying for implementations as I had figured (but it does require = extra memory, which I had hoped to see removed). However, I=E2=80=99m somewhat confused about your statement that the = framing information is the honest parties=E2=80=99 unique identifier of = the handshake. I had thought that TLS 1.3 was going to a model where = the handshake trace (and configuration, for 0-RTT) was the real session = identifier, and the nonces were there exclusively to make that trace = unique. This is a huge improvement from TLS 1.2, where the session = identifier is sometimes the nonces and sometimes the trace and sometimes = something in between (Server Certificate Verify eg). It further means = that future versions could drop the nonces entirely if they require = one-use ephemeral key exchange. It seems that you=E2=80=99re suggesting = that the session identifier is the tuple (nonces, trace, configuration), = which seems redundant to me. Perhaps it is required by the security = model (eCK?) to have a stable session identifier? I=E2=80=99m concerned about parseability in two ways. One, if the = nonces ever change size in future versions, or are omitted due to = required one-use ephemeral key exchange, then we will have to change how = handshake_hash is calculated, and we will have to make sure that it = cannot cause problems due to collisions with the current handshake_hash = calculation. Two, if the handshake messages fed into the hash function are not = uniquely parseable, that=E2=80=99s going to be a serious problem for = analyzing TLS 1.3, and should be a top priority to fix. Cheers, =E2=80=94 Mike --Apple-Mail=_91EA2F86-008F-4EB7-8943-65F33B2BB420 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Whoops, big-R to reply all...

On = Dec 17, 2015, at 9:39 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:


On Thu, Dec 17, 2015 at = 5:33 PM, Mike Hamburg <mike@shiftleft.org> wrote:


On Dec 17, 2015, at 12:11 PM, = Eric Rescorla <ekr@rtfm.com> wrote:



On Thu, Dec 17, 2015 at 3:02 PM, Hugo = Krawczyk <hugo@ee.technion.ac.il> wrote:
I have mentioned this in private conversations but = let me say this here: I would prefer that the nonces be explicitly = concatenated to the handshake hash.  That is, 

handshake_hash =3D Hash(
               =
             client =
random            ||
                            server random            =
||
                            Hash(handshake_messages) =
||
           =
                 Hash(configuration)      ||
                           )

The reason is that nonces are essential for = freshness and session uniqueness and I want to see them explicitly = included in the signed/mac-ed/KDF-ed information. I can envision a = future variant/mode of the protocol where parties do not transmit nonces = but have a synchronized state that they advance separately and use as = nonces (e.g., for key refreshing) - in such case the nonces would not be = included in the handshake-hash computation.

So while the redundancy of having them twice in the = handshake_hash calculation may be annoying, this adds robustness to the = security (and analysis) of the = protocol.
 
This change doesn't make implementation or specification = significantly more difficult.
Does anyone =  else object or feel it makes analysis harder? :)

-Ekr

While I haven=E2=80=99t been = following TLS 1.3 development all that closely, I will question this = request.

TLS = is annoying to implement and analyze in part because it hashes = more-or-less arbitrary parts of the handshake messages together, in = arbitrary order, at arbitrary times.  Removal of all the explicit = hashing of client/server random in TLS 1.3 makes it clearer what=E2=80=99s= going on, and makes implementations simpler. 

=E2=80=8BHow does removal of explicit hashing of the nonces = make things clearer? What are the things that are made = clearer?

=E2=80=8B
 
 Some of the crypto = operations still feel pretty arbitrary (particularly Finished), but = things seem to be improving overall.  In this context, it feels = like
=E2=80=8B=E2=80=8B
 adding client random = and server random back to the hash is a = regression.

=E2=80=8BWhat do you mean by = =E2=80=8B
 
=E2=80=8B"
<= div class=3D"gmail_default" style=3D"font-family: verdana, sans-serif; = display: inline;">=E2=80=8B
 adding client random and server = random back to the hash is a regression
=E2=80=8B"?
Why "back"? Were they removed? = What's the regression?
You are probably not suggesting to = omit them, right? Are you worried about the redundancy of being hashed = twice? Is it a security issue or an implementation = issue?
=E2=80=8B
.=E2=80=8B

=46rom an analysis point of view, the client and server = random are parseable from Hash(handshake messages) because they are = concatenated with framing information.

=E2=80=8BThey are parseable, but I am not sure they are = *uniquely* parseable - a fixed location in the stream does make them = uniquely parseable.

=E2=80=8B
 
 But here, they are = concatenated without framing information. =  

=E2=80=8BThe nonces are the main = framing information - they are the (honest parties') unique identifier = of the handshake.

=E2=80=8B
 
So I don=E2=80=99t understand = Hugo=E2=80=99s contention that the old scheme leads to trouble if the = nonce changes sizes in a later version, and that the new scheme does = not.  It seems to me that the reverse is more likely to be = true.

=E2=80=8BI'm clearly not following = your argument.

=E2=80=8BHugo
=E2=80=8B

Cheers,
=E2=80=94 = Mike

Sorry Hugo, I misread the proposal = as using the nonces and handshake hash when signing, but not elsewhere. =  On rereading, it is still entirely consistent, and isn=E2=80=99t = being added =E2=80=9Cback=E2=80=9D anywhere, except perhaps to some = memory structure in the handshake code.  It also definitely isn=E2=80= =99t a security problem, and it isn=E2=80=99t as annoying for = implementations as I had figured (but it does require extra memory, = which I had hoped to see removed).

However, I=E2=80=99m somewhat confused = about your statement that the framing information is the honest = parties=E2=80=99 unique identifier of the handshake.  I had thought = that TLS 1.3 was going to a model where the handshake trace (and = configuration, for 0-RTT) was the real session identifier, and the = nonces were there exclusively to make that trace unique.  This is a = huge improvement from TLS 1.2, where the session identifier is sometimes = the nonces and sometimes the trace and sometimes something in between = (Server Certificate Verify eg).  It further means that future = versions could drop the nonces entirely if they require one-use = ephemeral key exchange.  It seems that you=E2=80=99re suggesting = that the session identifier is the tuple (nonces, trace, configuration), = which seems redundant to me.  Perhaps it is required by the = security model (eCK?) to have a stable session identifier?

I=E2=80=99m concerned = about parseability in two ways.  One, if the nonces ever change = size in future versions, or are omitted due to required one-use = ephemeral key exchange, then we will have to change how handshake_hash = is calculated, and we will have to make sure that it cannot cause = problems due to collisions with the current handshake_hash = calculation.

Two, if the handshake messages fed into the hash function are = not uniquely parseable, that=E2=80=99s going to be a serious problem for = analyzing TLS 1.3, and should be a top priority to fix.

Cheers,
=E2=80=94 Mike

= --Apple-Mail=_91EA2F86-008F-4EB7-8943-65F33B2BB420-- From nobody Fri Dec 18 13:29:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D599F1B3924 for ; Fri, 18 Dec 2015 13:29:08 -0800 (PST) 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, 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 12RtGVRxlv0D for ; Fri, 18 Dec 2015 13:29:07 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4527C1B3923 for ; Fri, 18 Dec 2015 13:29:07 -0800 (PST) Received: by mail-ob0-x22e.google.com with SMTP id 18so88331882obc.2 for ; Fri, 18 Dec 2015 13:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=lwiySUQchSdJCqmy+ag81CvvuqfVrK+2s/h/aEJ6Le0=; b=Fspkyr/SKVSZJcKtXB4JfhDhCsK3MStnCnLO6+h3CdnH0psO3oI66vFFgbsjpUzPpz SK+FRZnQK6YV6PL3lhE7izAxRoVHFObmxNlL0rZaWaLQqmd6P+GzUTgerO517pcwqmn7 /TcOpKIbfY0goKeP8Yp2VaKVT+A+S+cRcJo7vEDzHZeqEAQFdRdbmM+AstezY+oWv3dy elPDSIhX/aDEeuslNLO+TPJjnbk5foJjcq+o1lzxdi7hU5Yk9IOurI4q35ZElfdGugS3 TPlT3I8TaJxltxUUXHdslL006bRy61qLimDWmZYFx8FwOH0JCsU6MNcZRi9wrFBUWPLv wfWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=lwiySUQchSdJCqmy+ag81CvvuqfVrK+2s/h/aEJ6Le0=; b=lsX3FK2hBljg12iRqFWG02KGT8uVDKuj8/mlBQd8Z6Z2EFa3+un1NUjlN9I94Lx5TY MgorFLlo1y9nTIJWSlzezsImz9eFGjQntU/Ryz1eIxnjKTu498LUPE51RUN2p71hfwae 6lf+U2JSBMZJzJLMm3h5hGcZWmvG4Kv/t6au5IMUavuEOdf63ROzIqFVgOvMyKN3w+fK nDiNmUShVUE8xJ7OiyCYHd9n7jgFa4I0MIhTeBugF7o4PkrEEaoNZMtZeBtc6kEnD15N 38MVW+xOwZojMyaVm44PiIPGNi7YxdQrEPDMd/RKZ2Yz9nxwviefkGwUGunWFz4XbJYe dv8A== X-Gm-Message-State: ALoCoQlDyeThIlOm34iL3OovmVpy7J/+PBhxxivKSsfkDtmekUInFf8xoVLBqmOBiGRasBfIki8z6u/QD41olEmad+gQXKgYzg== MIME-Version: 1.0 X-Received: by 10.60.82.101 with SMTP id h5mr2601058oey.44.1450474146460; Fri, 18 Dec 2015 13:29:06 -0800 (PST) Received: by 10.76.62.8 with HTTP; Fri, 18 Dec 2015 13:29:05 -0800 (PST) Date: Fri, 18 Dec 2015 11:29:05 -1000 Message-ID: From: Brian Smith To: "" Content-Type: multipart/alternative; boundary=047d7b676d3e41ac60052732d4f8 Archived-At: Subject: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2015 21:29:09 -0000 --047d7b676d3e41ac60052732d4f8 Content-Type: text/plain; charset=UTF-8 Hi, The recent renaming of the ChaCha20-Poly1305 cipher suites brought something to my attention that I hadn't thought about before. It seems like it might be better to use HKDF-SHA512 instead of HKDF-SHA512, and then rename the ChaCha20-Poly1305 cipher suites to _SHA512. Or, use SHA-384. It seems like ChaCha20-Poly1305 is likely to be implemented along with Ed26619 and x25519. Ed25519 already has a hard requirement of SHA-512; see [1]. Also, existing TLS cipher suites with 256-bit keys, the TLS_*_AES_256_GCM_SHA384 cipher suites, use SHA-384 as the PRF digest; see [2]. Note that SHA-384 is SHA-512 with a different IV, truncated to 384 bits. I've heard that Apple's HomeKit protocol also uses HKDF-SHA512 (With Ed25519 and x25519). Ed25519, x25519, ChaCha20-Poly1305, and HomeKit (I've heard) are all designed for ease of safe, fast, implementation on devices with limited resources. In particular, such devices might prefer to have a larger and faster implementation of SHA512 but a smaller and slower SHA-256, and/or forgo SHA-256 completely. Or, they might have a hardware implementation of SHA-512 instead of a the more-common-today hardware implementation of SHA-256. Thus, it is far from obvious that SHA-256 is the best choice for these cipher suites. WDYT? [1] https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-02#section-5 [2] https://tools.ietf.org/html/rfc5289#section-3.2. Cheers, Brian -- https://briansmith.org/ --047d7b676d3e41ac60052732d4f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The recent renaming of the ChaCha20= -Poly1305 cipher suites brought something to my attention that I hadn't= thought about before.=C2=A0It seems like it might be better to use HKDF-SHA512 instead of HKD= F-SHA512, and then rename the=C2=A0ChaCha20-Poly1305 cipher suites to _SHA5= 12. Or, use SHA-384.

It seems like ChaCha20= -Poly1305 is likely to be implemented along with Ed26619 and x25519. Ed2551= 9 already has a hard requirement of SHA-512; see [1].

<= div>Also, existing TLS cipher suites with 256-bit keys, the TLS_*_AES_256_GCM_SHA384 cipher su= ites, use SHA-384 as the PRF digest; see [2]. Note that SHA-384 is SHA-512 = with a different IV, truncated to 384 bits.

I've heard that Apple'= s HomeKit protocol also uses HKDF-SHA512 (With Ed25519 and x25519).<= /div>

Ed2551= 9, x25519, ChaCha20-Poly1305, and HomeKit (I've heard) are all designed= for ease of safe, fast, implementation on devices with limited resources. = In particular, such devices might prefer to have a larger and faster implem= entation of SHA512 but a smaller and slower SHA-256, and/or forgo SHA-256 c= ompletely. Or, they might have a hardware implementation of SHA-512 instead= of a the more-common-today hardware implementation of SHA-256.

Thus, it i= s far from obvious that SHA-256 is the best choice for these cipher suites.=
<= br>

--047d7b676d3e41ac60052732d4f8-- From nobody Fri Dec 18 13:43:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A781B3939 for ; Fri, 18 Dec 2015 13:43:45 -0800 (PST) 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, 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 V87hKuOOaZZu for ; Fri, 18 Dec 2015 13:43:44 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8491B3935 for ; Fri, 18 Dec 2015 13:43:44 -0800 (PST) Received: by mail-ob0-x22e.google.com with SMTP id sd4so89576739obb.0 for ; Fri, 18 Dec 2015 13:43:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ExMr7LREUC/EPyCCKg69ndoyfxMjcEAwoqJqHGNSPXY=; b=lnd3XZIynSVOjik/zI4eHe/e5F1r9J03quCxt/pH3B41BhZpPla21wWEG4HJeA60/d Jnz7ZzYO/x9iYUAdkdMg4d26KbZ4Kebokv4Cv+PluqsNhzwq2Fwb6xF0kGbq02eIPBsI aEHMVECaKiWFIUE9re98kqpz3r0OedhhtI4uu+pE0ycN7TJBTvQcr5sa/vh9uAN3wn36 OeuMfWk70tiPg6E+0addYxK2cBCovv1Cr/5Z0uF0Ig6fJJuzfGV5DxBOJD1gqONN1td2 tVrajAxmiLde6lekpkN45kACYf3ZA6gkqbD16yTYrmVB7P460mtK9lIhlRAGrxc2wPi0 AUJw== 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:content-type; bh=ExMr7LREUC/EPyCCKg69ndoyfxMjcEAwoqJqHGNSPXY=; b=lAUysZxdRdRJ9ndWUHbrc65YcnsVGmXRezxR93tU/tKE0Io1sSrhVkyze/lGlIqNNJ vg+CzGqBu9RCzFsTgdS9ePDkqfD8FFx0guK83R9SLpWcBYx7FMNtTEeNy2/u0FyRIBIj OGWpueuzaulUfUmaQ1dsI1TanSgpkaUDkGzDdYKxfaOIHXsbnWDQ+h2AuoQldvxqMHI6 GrFc4BAhPO0d6R6SlPWM4I76N6SrzLR6id3YrIOjD7UxBnh4rD/vA1TjIBN6EiUQhJS4 Sz24wICP0j+CnfsyBpV7a0ibtYgDhds1e4sm/QUc5KJGt3r+xvJ/PZn0KkSR59m8W0GO 44ZQ== X-Gm-Message-State: ALoCoQk8rXUqLAV+Frui6+HwvPSYRAAMw+IIJnEz90jHJLqXT9AyDo4Ab+7CTZKSDAA/wfvSSbsfQXq0LxFa58a2ml2bvzGI/Q== MIME-Version: 1.0 X-Received: by 10.182.125.38 with SMTP id mn6mr2655410obb.17.1450475024092; Fri, 18 Dec 2015 13:43:44 -0800 (PST) Received: by 10.76.62.8 with HTTP; Fri, 18 Dec 2015 13:43:44 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Dec 2015 11:43:44 -1000 Message-ID: From: Brian Smith To: "" Content-Type: multipart/alternative; boundary=089e012952ec91246a0527330881 Archived-At: Subject: Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2015 21:43:45 -0000 --089e012952ec91246a0527330881 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 18, 2015 at 11:29 AM, Brian Smith wrote: > Hi, > > The recent renaming of the ChaCha20-Poly1305 cipher suites brought > something to my attention that I hadn't thought about before. It seems > like it might be better to use HKDF-SHA512 instead of HKDF-SHA512, and > That is, it seems it would be better to use HKDF-SHA512 instead of **HKDF-SHA256**. Cheers, Brian --089e012952ec91246a0527330881 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Dec 18, 2015 at 11:29 AM, Brian Smith <brian@briansmith.org>= wrote:
Hi,
<= br>
The recent renaming of the ChaCha20-Poly1305 cipher suites br= ought something to my attention that I hadn't thought about before.=C2= =A0It seems like it= might be better to use HKDF-SHA512 instead of HKDF-SHA512, and

That is, it seems it would be bett= er to use HKDF-SHA512 instead of **HKDF-SHA256**.

= Cheers,
Brian
--089e012952ec91246a0527330881-- From nobody Fri Dec 18 14:45:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E011B39BA for ; Fri, 18 Dec 2015 14:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 enpCPLpj5DiL for ; Fri, 18 Dec 2015 14:45:37 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:796]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795F11B39BF for ; Fri, 18 Dec 2015 14:45:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HWSedEeadCrIpPbTQvTeJWxsAlm+uTsFaRdHZzb0Q50=; b=d/ee4rmdKQ2SYKAzWGzHMwnWC2i03jhuUcCAxy+Vlkcv0qWGRzEoEiewK8C0dzWLbjHhIvaOEKbP/WWpSgnSXCdiJ+czJfPWYt0Qj00qu+SE0fXsVjqHtZLt8ESd0IzUJsRCQHtZu2gqZ1ixWtnpgs1KWwVI3HMITKgCunqW13M= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0654.namprd03.prod.outlook.com (10.160.96.16) with Microsoft SMTP Server (TLS) id 15.1.361.13; Fri, 18 Dec 2015 22:45:15 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0361.006; Fri, 18 Dec 2015 22:45:15 +0000 From: Christian Huitema To: "tls@ietf.org" Thread-Topic: Do we really need two 0-RTT keys? Thread-Index: AdE545+dJMVvs5LHSUe65W5oKcLEUQ== Date: Fri, 18 Dec 2015 22:45:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [131.107.159.119] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0654; 5:MZC5LzMvXviaDEv3rd0tINaegQTbVxMBWxkpIIAkkWbFBfVM4ppj+41O5JXsaQCkc40PxOa/92cLiV2kSQCmKRAxYvumiigPX14RZL47eyoupc/jRwabzOZrDKCwOIiMtRom4E0yIr0vHvQGvpzKmQ==; 24:zOeYgnFYeAXW/NQQrx+U9QJxl9N9fSsyB9jdjLkm6ARyLLUOzoDKPiGBs+LQS8Pjo97RrySJIu2JgCgmNllpaZh8727AQOrH41EmXN0+QOA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0654; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:DM2PR0301MB0654; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0654; x-forefront-prvs: 07943272E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(5001960100002)(107886002)(106356001)(189998001)(81156007)(105586002)(54356999)(99286002)(110136002)(86362001)(86612001)(101416001)(5003600100002)(50986999)(66066001)(74316001)(97736004)(2900100001)(33656002)(76576001)(3846002)(2501003)(2351001)(11100500001)(77096005)(450100001)(87936001)(8990500004)(1730700002)(229853001)(10400500002)(5004730100002)(40100003)(92566002)(5002640100001)(586003)(5005710100001)(10090500001)(122556002)(6116002)(10290500002)(1220700001)(5008740100001)(102836003)(1096002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0654; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2015 22:45:15.8211 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0654 Archived-At: Subject: [TLS] Do we really need two 0-RTT keys? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2015 22:45:40 -0000 The ladder diagram describing the 0-RTT exchange is simple enough, as seen = in this extract: Client Server =20 ClientHello + KeyShare + EarlyDataIndication ^ (Certificate*) 0-RTT | (CertificateVerify*) Data | (Finished) v (Application Data*) (end_of_early_data) --------> The text indicates that client auth and application data messages are prote= cted by "keys derived from the static secret." But then, hidden in section = 7.2 is an interesting twist -- too different keys are supposed to be derive= d from the static secret, one for 0-RTT handshake, another for 0-RTT Applic= ation. If I understand correctly, the Certificate, CertificateVerify and Cl= ient Finished message would be protected with the "0-RTT Handshake" key, an= d the Application data and end-of-early data message would be protected wit= h the "0-RTT Application" key. I assume that there is a good reason for this extra complexity, even if it = eludes me. But I worry a bit about what that would do when we start working= on DTLS 1.3. UDP messages can arrive out of order. Yes, there is a message= number, but the record layer is not necessarily well positioned to interpr= et it -- the certificate and verify message are optional, so when a record = layer receives packet #3 before packet #2, it does not know whether this is= a CertificateVerify message (handshake key) or an application message (app= lication key).=20 Yes, there are solutions, yes, it can be managed, but are we sure that this= particular bit of complexity is worth it? And if it worth it, can we add a description of the key switching logic in = section 6.2.2? -- Christian Huitema From nobody Fri Dec 18 15:02:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EC81A0013 for ; Fri, 18 Dec 2015 15:02:51 -0800 (PST) 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, HTML_MESSAGE=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 gArhFTyo6SuS for ; Fri, 18 Dec 2015 15:02:49 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFFC1A000B for ; Fri, 18 Dec 2015 15:02:49 -0800 (PST) Received: by mail-yk0-x22f.google.com with SMTP id x184so75949727yka.3 for ; Fri, 18 Dec 2015 15:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9ZLmu9zqhgXicbRiiY1Xg81qCv7tvpK1XFumCknT5Vw=; b=lwIvKO6+tRSkP6ryNX1KGYSl++kadwEI1RNDPzBqGwBg1pEUGhGcM/gNKwl+mu1Cg1 WNB8jiSXOKEJBiU3a1jHUFPDZp9Lm3rixsGYfWbbxcdF/92X2RmRCZNP3bYcu8TXoSdJ Naz2jE+RMJEuFkZ7CcVHR+8jallclzKXWu1Y4tDsW6EjZ/gGyAmYTJef2i03SY6Zt0+X cb06eLkqZr93+pnOglbO4M4+qlHhPYozr4ARmI8C5pXcOnZikcsF0Dg+/qtFdx3CxMnK UuixYoYNeEk5FPPWMNHWSICbp+1chFbGhc8aIxQjn7NXII2Fw3MGHXxEKY/mLWIjrvfN scyg== 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=9ZLmu9zqhgXicbRiiY1Xg81qCv7tvpK1XFumCknT5Vw=; b=Dsdx8ZXeb44d0MRmuIb62ol9dKCSx4jBaE3PjubgpcGt8tjV08tIzUwIpzrA19KKFK gScQ0NKYL2bcYWUsQeYLj+BwvAynz0ZsTue6nGPYmiAcaNdxC5YCvV8IO3P1LegZ5hou J9RA15I/o3pifsL/IO+sl37PgQmPwqO4DTF2MNkK6Oj6tEc/cWWeGqSgaNGVdjdVAYhI bngRmAY4i7X97qZe5peK77uTAooxBz2gmpqa+RIv/Wwz1rSOOqyiBrMu0W9ey7ZQXXhE EVmYzsYav/v0ePxH7Hse5XTpCFAf3LqkJr9rSd3bYAGEKq7G77IJYe07vJBKU7h0dW4q i6Tw== X-Gm-Message-State: ALoCoQmcW9SXaRccELkiujOPPihFRlRaF9X4VtlGLw+dEXrvN2e2YZv10iK4xUvZCTrwt48A0YDpYGGTl8MGHCStHcHuNK5Dcw== X-Received: by 10.129.73.133 with SMTP id w127mr5872338ywa.223.1450479768709; Fri, 18 Dec 2015 15:02:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Fri, 18 Dec 2015 15:02:09 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 18 Dec 2015 15:02:09 -0800 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=001a114dcf6a5e5b9c05273423af Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Do we really need two 0-RTT keys? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Dec 2015 23:02:51 -0000 --001a114dcf6a5e5b9c05273423af Content-Type: text/plain; charset=UTF-8 On Fri, Dec 18, 2015 at 2:45 PM, Christian Huitema wrote: > The ladder diagram describing the 0-RTT exchange is simple enough, as seen > in this extract: > > Client Server > > ClientHello > + KeyShare > + EarlyDataIndication > ^ (Certificate*) > 0-RTT | (CertificateVerify*) > Data | (Finished) > v (Application Data*) > (end_of_early_data) --------> > > The text indicates that client auth and application data messages are > protected by "keys derived from the static secret." But then, hidden in > section 7.2 is an interesting twist -- too different keys are supposed to > be derived from the static secret, one for 0-RTT handshake, another for > 0-RTT Application. If I understand correctly, the Certificate, > CertificateVerify and Client Finished message would be protected with the > "0-RTT Handshake" key, and the Application data and end-of-early data > message would be protected with the "0-RTT Application" key. > Yes, that's correct. > I assume that there is a good reason for this extra complexity, even if it > eludes me. The motivation for this was that a number of people working on analysis complained that using the same key to encrypt handshake traffic and application traffic (as is done in TLS 1.2 with Finished and application messages) made analysis harder. I'm not equipped to take a position on this, but that's what I have been told. We already do that for the 1-RTT keys and we're doing the same thing here. > But I worry a bit about what that would do when we start working on DTLS > 1.3. UDP messages can arrive out of order. Yes, there is a message number, > but the record layer is not necessarily well positioned to interpret it -- > the certificate and verify message are optional, so when a record layer > receives packet #3 before packet #2, it does not know whether this is a > CertificateVerify message (handshake key) or an application message > (application key). > Note: the Certificate message isn't optional in the sense that the server doesn't know if it's coming. Whether it's sent is conditioned on the configuration (in WIP-11) an on the client's EarlyDataInfication (in WIP-10). But your general point is right in that you can have loss and reordering. So, for instance, say that the client sends messages with seq nums as follows: ClientHello: 0 (in clear) Finished: 1 (with Handshake Key) AppData: 2 (with app key) Now, 1 and 2 are lost, and the client retransmits: Finished: 3 (with Handshake Key) AppData: 4 (with app key) If #3 is now lost, the server may not know if #4 is handshake or application data since (for instance) the client might have fragmented the Finished over two records. Now, I think there are several ways to deal with this. First, the server can just continue to attempt to process records with the handshake key until the handshake is completed, in which case it will drop #4 and then get the retransmit of the Finished (#5, presumably). Second, DTLS has an epoch # used to indicate which generation key you are using. We should come down on some deterministic use of that in which case things will be obvious. Yes, there are solutions, yes, it can be managed, but are we sure that this > particular bit of complexity is worth it? > Karthik? Others? :) > And if it worth it, can we add a description of the key switching logic in > section 6.2.2? That seems like a good plan... Ekr > -- Christian Huitema > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114dcf6a5e5b9c05273423af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 18, 2015 at 2:45 PM, Christian Huitema &l= t;huitema@micros= oft.com> wrote:
The ladder = diagram describing the 0-RTT exchange is simple enough, as seen in this ext= ract:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Server

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ClientHello
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ KeyShare
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ EarlyDataIndication
=C2=A0 =C2=A0 =C2=A0 ^=C2=A0 (Certificate*)
0-RTT |=C2=A0 (CertificateVerify*)
Data=C2=A0 |=C2=A0 (Finished)
=C2=A0 =C2=A0 =C2=A0 v=C2=A0 (Application Data*)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(end_of_early_data)=C2=A0 =C2=A0 =C2=A0 = =C2=A0 -------->

The text indicates that client auth and application data messages are prote= cted by "keys derived from the static secret." But then, hidden i= n section 7.2 is an interesting twist -- too different keys are supposed to= be derived from the static secret, one for 0-RTT handshake, another for 0-= RTT Application. If I understand correctly, the Certificate, CertificateVer= ify and Client Finished message would be protected with the "0-RTT Han= dshake" key, and the Application data and end-of-early data message wo= uld be protected with the "0-RTT Application" key.

Yes, that's correct.

=C2= =A0
I assume that there is a good reason for this extra complexity, even if it = eludes me.

The motivation for this was that= a number of people working on analysis complained
that using the= same key to encrypt handshake traffic and application traffic (as
is done in TLS 1.2 with Finished and application messages) made analysis = harder.
I'm not equipped to take a position on this, but that= 's what I have been told. We
already do that for the 1-RTT ke= ys and we're doing the same thing here.

=C2=A0=
But I worry a bit about what that wou= ld do when we start working on DTLS 1.3. UDP messages can arrive out of ord= er. Yes, there is a message number, but the record layer is not necessarily= well positioned to interpret it -- the certificate and verify message are = optional, so when a record layer receives packet #3 before packet #2, it do= es not know whether this is a CertificateVerify message (handshake key) or = an application message (application key).

Note: the Certificate message isn't optional in the sense that the s= erver doesn't
know if it's coming. Whether it's sent = is conditioned on the configuration (in WIP-11)
an on the client&= #39;s EarlyDataInfication (in WIP-10).

But your ge= neral point is right in that you can have loss and reordering. So, for inst= ance,
say that the client sends messages with seq nums as follows= :

=C2=A0 =C2=A0 ClientHello: 0 (in clear)
=C2=A0 =C2=A0 Finished: 1 (with Handshake Key)
=C2=A0 =C2=A0 Ap= pData: =C2=A02 (with app key)

=C2=A0 =C2=A0 Now, 1= and 2 are lost, and the client retransmits:

=C2= =A0 =C2=A0 Finished: 3 (with Handshake Key)=C2=A0
=C2=A0 =C2=A0 A= ppData: 4 (with app key)

If #3 is now lost, the se= rver may not know if #4 is handshake or application data
sinc= e (for instance) the client might have fragmented the Finished over two
records.

Now, I think there are several way= s to deal with this. First, the server can just
continue to attem= pt to process records with the handshake key until the handshake
= is completed, in which case it will drop #4 and then get the retransmit of = the
Finished (#5, presumably). Second, DTLS has an epoch # used t= o indicate which
generation key you are using. We should come dow= n on some deterministic use of
that in which case things will be = obvious.


Yes, there are solutions, yes, it can be managed, but are we sure that this= particular bit of complexity is worth it?

<= div>Karthik? Others? :)

=C2=A0
And if it worth it, can we add a description of the key switching logic in = section 6.2.2?

That seems like a good plan.= ..

Ekr

=C2=A0
-- Christian Huitema


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

--001a114dcf6a5e5b9c05273423af-- From nobody Fri Dec 18 16:03:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923CC1A00DC for ; Fri, 18 Dec 2015 16:03:12 -0800 (PST) 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 8NFckbPUH8L7 for ; Fri, 18 Dec 2015 16:03:09 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C86421A00D5 for ; Fri, 18 Dec 2015 16:03:00 -0800 (PST) Received: by mail-lb0-x234.google.com with SMTP id yq9so52530869lbb.3 for ; Fri, 18 Dec 2015 16:03:00 -0800 (PST) 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=+BOeJ1SGaqzjW2UpKizdFZLPm3FZSAPymBo48d120cU=; b=PIyWnYc4yCgKVBHCzdU5e2fcVe494AFzSzXdcmDWPgeTjzTF607rUPVuougohu030X f/TBeTsXPttjLD1FTZahOeoCSxjtU1ZO7VOfARaFxSGSWy40K/XjbdZZkebulZGVWsnZ HkxcKJF5cf609Sz+udDjUafxKj9Ea0HS1tgTIECoM4QLu+rEKeQS0+wWJYfNd7+a/OAm kQM2BRnAf8BwEa63h8l+DZ8LhF6c6pnXjoPXueTYMGt5tsPBg/k7O+jW+k3uBzq9uNr0 qxkmcZrVO6Tu9/Umw/Mjq9DONZ8aqagKkbfnw25QI22x2oxnn3tr9D0JusaBrkGK6Vhn n91Q== X-Received: by 10.112.173.202 with SMTP id bm10mr2508376lbc.56.1450483378826; Fri, 18 Dec 2015 16:02:58 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.168.210 with HTTP; Fri, 18 Dec 2015 16:02:29 -0800 (PST) In-Reply-To: <518C2E3A-D72E-443D-80CF-C27E085292EC@shiftleft.org> References: <56718D7A.4000302@cisco.com> <201512161530.06122.davemgarrett@gmail.com> <5671D454.6000506@cisco.com> <201512161628.02986.davemgarrett@gmail.com> <5672D12D.4010003@cisco.com> <518C2E3A-D72E-443D-80CF-C27E085292EC@shiftleft.org> From: Hugo Krawczyk Date: Fri, 18 Dec 2015 19:02:29 -0500 X-Google-Sender-Auth: nnXgLr4xy5lFIsiAt-czjoBNXTI Message-ID: To: Mike Hamburg Content-Type: multipart/alternative; boundary=001a11c3440e8c32c3052734fa5c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Explicit use of client and server random values X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2015 00:03:12 -0000 --001a11c3440e8c32c3052734fa5c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 18, 2015 at 3:55 PM, Mike Hamburg wrote: > Whoops, big-R to reply all... > > On Dec 17, 2015, at 9:39 PM, Hugo Krawczyk wrote= : > > > On Thu, Dec 17, 2015 at 5:33 PM, Mike Hamburg wrote: > >> >> >> On Dec 17, 2015, at 12:11 PM, Eric Rescorla wrote: >> >> >> >> On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk >> wrote: >> >>> I have mentioned this in private conversations but let me say this here= : >>> I would prefer that the nonces be explicitly concatenated to the handsh= ake >>> hash. That is, >>> >>> handshake_hash =3D Hash( >>> >>> client random || >>> >>> server random || >>> >>> Hash(handshake_messages) || >>> >>> Hash(configuration) || ) >>> >>> >>> The reason is that nonces are essential for freshness and session >>> uniqueness and I want to see them explicitly included in the >>> signed/mac-ed/KDF-ed information. I can envision a future variant/mode = of >>> the protocol where parties do not transmit nonces but have a synchroniz= ed >>> state that they advance separately and use as nonces (e.g., for key >>> refreshing) - in such case the nonces would not be included in the >>> handshake-hash computation. >>> >>> So while the redundancy of having them twice in the handshake_hash >>> calculation may be annoying, this adds robustness to the security (and >>> analysis) of the protocol. >>> >> >> This change doesn't make implementation or specification significantly >> more difficult. >> Does anyone else object or feel it makes analysis harder? :) >> >> -Ekr >> >> >> While I haven=E2=80=99t been following TLS 1.3 development all that clos= ely, I >> will question this request. >> >> TLS is annoying to implement and analyze in part because it hashes >> more-or-less arbitrary parts of the handshake messages together, in >> arbitrary order, at arbitrary times. Removal of all the explicit hashin= g >> of client/server random in TLS 1.3 makes it clearer what=E2=80=99s going= on, and >> makes implementations simpler. >> > > =E2=80=8BHow does removal of explicit hashing of the nonces make things c= learer? > What are the things that are made clearer? > > =E2=80=8B > > >> Some of the crypto operations still feel pretty arbitrary (particularly >> Finished), but things seem to be improving overall. In this context, it >> feels like >> =E2=80=8B=E2=80=8B >> adding client random and server random back to the hash is a regression= . >> > > =E2=80=8BWhat do you mean by =E2=80=8B > > =E2=80=8B" > =E2=80=8B > adding client random and server random back to the hash is a regression > =E2=80=8B"? > Why "back"? Were they removed? What's the regression? > You are probably not suggesting to omit them, right? Are you worried abou= t > the redundancy of being hashed twice? Is it a security issue or an > implementation issue? > =E2=80=8B > .=E2=80=8B > >> >> From an analysis point of view, the client and server random are >> parseable from Hash(handshake messages) because they are concatenated wi= th >> framing information. >> > > =E2=80=8BThey are parseable, but I am not sure they are *uniquely* parsea= ble - a > fixed location in the stream does make them uniquely parseable. > > =E2=80=8B > > >> But here, they are concatenated without framing information. >> > > =E2=80=8BThe nonces are the main framing information - they are the (hone= st > parties') unique identifier of the handshake. > > =E2=80=8B > > >> So I don=E2=80=99t understand Hugo=E2=80=99s contention that the old sch= eme leads to >> trouble if the nonce changes sizes in a later version, and that the new >> scheme does not. It seems to me that the reverse is more likely to be t= rue. >> > > =E2=80=8BI'm clearly not following your argument. > > =E2=80=8BHugo > =E2=80=8B > >> >> Cheers, >> =E2=80=94 Mike >> > > Sorry Hugo, I misread the proposal as using the nonces and handshake hash > when signing, but not elsewhere. On rereading, it is still entirely > consistent, and isn=E2=80=99t being added =E2=80=9Cback=E2=80=9D anywhere= , except perhaps to some > memory structure in the handshake code. It also definitely isn=E2=80=99t= a > security problem, and it isn=E2=80=99t as annoying for implementations as= I had > figured (but it does require extra memory, which I had hoped to see > removed). > > However, I=E2=80=99m somewhat confused about your statement that the fram= ing > information is the honest parties=E2=80=99 unique identifier of the hands= hake. I > had thought that TLS 1.3 was going to a model where the handshake trace > (and configuration, for 0-RTT) was the real session identifier, and the > nonces were there exclusively to make that trace unique. > In analysis we build on unique session identifiers which can be defined in different ways but need always be part of the authenticated information (sometimes, authentication can be implicit, i.e. non-explicit, by making this information part of the input to the KDF). When parties share state, state information may be used as part of the unique session identifier. If this part is not transmitted and you only authenticate information that went over the wire you may be missing important inputs to authentication/KDF. =E2=80=8BI cannot predict all ways people can eventually construct logical = session identifiers but I can hope that these will always include session-specific nonces, hence I want to make sure that they get included in the authentication inputs (which in TLS 1.3 is governed by the handshake_hash).= =E2=80=8B Of course, nonces by themselves are often not sufficient as session identifiers but they are an essential piece [0]. =E2=80=8B > This is a huge improvement from TLS 1.2, where the session identifier is > sometimes the nonces and sometimes the trace and sometimes something in > between (Server Certificate Verify eg). It further means that future > versions could drop the nonces entirely if they require one-use ephemeral > key exchange. > =E2=80=8BSee [0] =E2=80=8B > It seems that you=E2=80=99re suggesting that the session identifier is t= he tuple > (nonces, trace, configuration), which seems redundant to me. Perhaps it = is > required by the security model (eCK?) to have a stable session identifier= ? > =E2=80=8BI believe that any security model will need a unique way to refer = to a session and bind information to it. =E2=80=8B > > I=E2=80=99m concerned about parseability in two ways. One, if the nonces= ever > change size in future versions, or are omitted due to required one-use > ephemeral key exchange, then we will have to change how handshake_hash is > calculated, and we will have to make sure that it cannot cause problems d= ue > to collisions with the current handshake_hash calculation. > > Two, if the handshake messages fed into the hash function are not uniquel= y > parseable, that=E2=80=99s going to be a serious problem for analyzing TLS= 1.3, and > should be a top priority to fix. > =E2=80=8BI, too, assume that non-unique parseability can create all kind of problems. But I can also see parseability rules changing in protocol variants/derivatives. The "insurance"=E2=80=8B =E2=80=8B in the form of prepended nonces does not seem to be too much of a= burden. But as I said in my initial posting, if this is considered a burden from implementation point of view (or for any other reason) then it is not a tragedy to keep it as currently defined but a note on the necessity of transmitting nonces, as well as their unique parsing, should be included. Hugo [0] You mention the possibility of nonces being redundant in some cases, e.g. when you send fresh DH values in each session for forward secrecy and use these values in lieu of nonces (or as part of the naming of your session). To me this is a good example of things people should NOT be doing. For example, even if you specify that DH values MUST not be used twice, there is no way to enforce that and someone (or a new protocol/application) can decide that re-using a DH value for one minute gives good enough forward secrecy. In many cases I would agree with that. But then, if you also built on the DH values as nonces, then that decision just broke your security. Conclusion: Always use dedicated nonces for ensuring uniquenes of session identifiers and session binding for authentication. =E2=80=8B > > Cheers, > =E2=80=94 Mike > > --001a11c3440e8c32c3052734fa5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 18, 2015 at 3:55 PM, Mike Hamburg <mike@= shiftleft.org> wrote:
Whoops, big-R to reply all...

On Dec 17, 2015,= at 9:39 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:


On Thu, Dec 17, 2015 at 5:33 PM, Mike Hamburg<= span>=C2=A0<mike@shiftleft.org>=C2=A0wrote:


On Dec 17, 2015, at 12:11 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk=C2=A0<hu= go@ee.technion.ac.il>=C2=A0wrote:
I have mentioned this in private conversations but let me say thi= s here: I would prefer that the nonces be explicitly concatenated to the ha= ndshake hash.=C2=A0 That is,=C2=A0

handshake_hash =3D Hash(
                            client random            ||
                            s=
erver random            ||
=
                            Hash(handsh=
ake_messages) ||
          =
                  Hash(configuration)      ||
                           )

The reason is that nonces are essen= tial for freshness and session uniqueness and I want to see them explicitly= included in the signed/mac-ed/KDF-ed information. I can envision a future = variant/mode of the protocol where parties do not transmit nonces but have = a synchronized state that they advance separately and use as nonces (e.g., = for key refreshing) - in such case the nonces would not be included in the = handshake-hash computation.

So while the re= dundancy of having them twice in the handshake_hash calculation may be anno= ying, this adds robustness to the security (and analysis) of the protocol.<= /div>
=C2=A0
This change doesn't= make implementation or specification significantly more difficult.
Does anyone =C2=A0else object or feel it makes analysis harder? :)
=

-Ekr

While I haven=E2=80=99t been following TLS 1.3 development al= l that closely, I will question this request.

TLS = is annoying to implement and analyze in part because it hashes more-or-less= arbitrary parts of the handshake messages together, in arbitrary order, at= arbitrary times.=C2=A0 Removal of all the explicit hashing of client/serve= r random in TLS 1.3 makes it clearer what=E2=80=99s going on, and makes imp= lementations simpler.=C2=A0

=E2=80= =8BHow does removal of explicit hashing of the nonces make things clearer? = What are the things that are made clearer?

=E2=80=8B=C2=A0
=C2=A0Some of the cry= pto operations still feel pretty arbitrary (particularly Finished), but thi= ngs seem to be improving overall.=C2=A0 In this context, it feels like
=E2= =80=8B=E2=80=8B
=C2=A0adding client random and server ran= dom back to the hash is a regression.

=E2=80=8BWh= at do you mean by =E2=80=8B
=C2=A0
=E2=80=8B"
=E2=80=8B
=C2=A0adding= client random and server random back to the hash is a regression
=E2=80= =8B"?
Why "back"? Were they removed? What's the = regression?
You are probably not suggesting to omit them, right? Ar= e you worried about the redundancy of being hashed twice? Is it a security = issue or an implementation issue?
=E2=80=8B
.=E2=80=8B

From an analysis point of view, the client an= d server random are parseable from Hash(handshake messages) because they ar= e concatenated with framing information.

=E2=80= =8BThey are parseable, but I am not sure they are *uniquely* parseable - a = fixed location in the stream does make them uniquely parseable.
=

<= /div>
=
=E2=80=8B
=C2=A0
=C2=A0Bu= t here, they are concatenated without framing information. =C2=A0

=E2=80=8BThe nonces are the main framing information - the= y are the (honest parties') unique identifier of the handshake.
<= br>
=E2=80=8B
=C2=A0
So I= don=E2=80=99t understand Hugo=E2=80=99s contention that the old scheme lea= ds to trouble if the nonce changes sizes in a later version, and that the n= ew scheme does not.=C2=A0 It seems to me that the reverse is more likely to= be true.

=E2=80=8BI'm clearly not following = your argument.

=E2=80=8BHugo
=E2=80=8B
=

Cheers,
=E2= =80=94 Mike

Sorry Hugo, I misread the proposal as using th= e nonces and handshake hash when signing, but not elsewhere.=C2=A0 On rerea= ding, it is still entirely consistent, and isn=E2=80=99t being added =E2=80= =9Cback=E2=80=9D anywhere, except perhaps to some memory structure in the h= andshake code.=C2=A0 It also definitely isn=E2=80=99t a security problem, a= nd it isn=E2=80=99t as annoying for implementations as I had figured (but i= t does require extra memory, which I had hoped to see removed).
<= br>
However, I=E2=80=99m somewhat confused about your statement t= hat the framing information is the honest parties=E2=80=99 unique identifie= r of the handshake.=C2=A0 I had thought that TLS 1.3 was going to a model w= here the handshake trace (and configuration, for 0-RTT) was the real sessio= n identifier, and the nonces were there exclusively to make that trace uniq= ue.

In analysis we build on unique session identifiers which can b= e defined in different ways but need always be part of the authenticated in= formation (sometimes, authentication can be implicit, i.e. non-explicit, by= making this information part of the input to the KDF).=C2=A0
When parties share state, state information ma= y be used as part of the unique session identifier. If this part is not tra= nsmitted and you only authenticate information that went over the wire you = may be missing important inputs to authentication/KDF.
=E2=80=8BI cannot predict all ways people can eventually construct l= ogical session identifiers but I can hope that these will always include se= ssion-specific nonces, hence I want to make sure that they get included in = the authentication inputs (which in TLS 1.3 is governed by the handshake_ha= sh).=E2=80=8B
Of course, nonces by themselves are often not= sufficient as session identifiers but they are an essential piece [0].
=C2=A0=E2=80=8B
=C2=A0
=C2=A0This is a huge improvement from TLS 1.2, where th= e session identifier is sometimes the nonces and sometimes the trace and so= metimes something in between (Server Certificate Verify eg).=C2=A0 It furth= er means that future versions could drop the nonces entirely if they requir= e one-use ephemeral key exchange.

=E2=80=8BSee [0]
=E2=80=8B
=C2=A0
= =C2=A0It seems that you=E2=80=99re suggesting that the session identifier i= s the tuple (nonces, trace, configuration), which seems redundant to me.=C2= =A0 Perhaps it is required by the security model (eCK?) to have a stable se= ssion identifier?

=
=E2=80=8BI believe that any security model will n= eed a unique way to refer to a session and bind information to it.
=E2=80=8B
=C2=A0
=

I=E2=80=99m concerned about parseability in two ways.= =C2=A0 One, if the nonces ever change size in future versions, or are omitt= ed due to required one-use ephemeral key exchange, then we will have to cha= nge how handshake_hash is calculated, and we will have to make sure that it= cannot cause problems due to collisions with the current handshake_hash ca= lculation.

Two, if the handshake messages fed into= the hash function are not uniquely parseable, that=E2=80=99s going to be a= serious problem for analyzing TLS 1.3, and should be a top priority to fix= .

=E2=80=8BI, too, assume that non-unique parseability can create a= ll kind of problems. But I can also see parseability rules changing in prot= ocol variants/derivatives. The "insurance"=E2=80=8B
=C2=A0=E2=80=8B in the form of prepended nonces does not = seem to be too much of a burden.=C2=A0
But as I said in my initial posting, if this is considered a burden f= rom implementation point of view (or for any other reason) then it is not a= tragedy to keep it as currently defined but a note on the necessity of tra= nsmitting nonces, as well as their unique parsing, should be included.

Hugo

[0] You mention the possibility of nonces bein= g redundant in some cases, e.g. when you send fresh DH values in each sessi= on for forward secrecy and use these values in lieu of nonces (or as part o= f the naming of your session). To me this is a good example of things peopl= e should NOT be doing. For example, even if you specify that DH values MUST= not be used twice, there is no way to enforce that and someone (or a new p= rotocol/application) can decide that re-using a DH value for one minute giv= es good enough forward secrecy. In many cases I would agree with that. But = then, if you also built on the DH values as nonces, then that decision just= broke your security.=C2=A0
Concl= usion: Always use dedicated nonces for ensuring uniquenes of session identi= fiers and session binding for authentication.
=E2=80=8B

Cheer= s,
=E2=80=94 Mike

=
--001a11c3440e8c32c3052734fa5c-- From nobody Fri Dec 18 16:41:34 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F3A1A014B for ; Fri, 18 Dec 2015 16:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_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 TlVdvQOY0mmU for ; Fri, 18 Dec 2015 16:41:30 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0139.outbound.protection.outlook.com [65.55.169.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75F391A014D for ; Fri, 18 Dec 2015 16:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6nZZiv+irn8P1v0qXRbwyvHHo04fSu6Udcx/7aqZ9A4=; b=cG6PJT/05vaBV4r/2CG8Ip60xGhqHcbCACvy7bEHpzl5AdbnZ+U/fkEHrLKHA8w1NPOYhcVtdBK+V005aR8mlqUBHQRVwXvee+szTLf4yraJ9OFRCyHPAEFmkL0OzE7CnIn80noWzzPmHXia8Oli+RQzz/hMnlVGwZr6pVbdxys= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0654.namprd03.prod.outlook.com (10.160.96.16) with Microsoft SMTP Server (TLS) id 15.1.361.13; Sat, 19 Dec 2015 00:41:28 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0361.006; Sat, 19 Dec 2015 00:41:28 +0000 From: Christian Huitema To: Eric Rescorla Thread-Topic: [TLS] Do we really need two 0-RTT keys? Thread-Index: AdE545+dJMVvs5LHSUe65W5oKcLEUQABH+iAAALoXtA= Date: Sat, 19 Dec 2015 00:41:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [131.107.159.119] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0654; 5:OPsp6JiPRplMS1/9b1WlLQLCBxAJhsqYRNfXINfG/2AvcMvua2k8MzGH+sWIzLzz7mnINmAyvrPTwF/CjpiXSCRNDyWgKjnqH8DBQiwIp4ueNe6pi7+D6pklHU/pUEQkINdOkkR9fd4KTwUXjHX50g==; 24:TzAyY9v/bP2yRxDJQufP91bt7496Ai8+MekENHDBC4PPmXPtxBRrPJyUKWp2Jn44fDLzStXjvixZNp5uaXs4ofFQlpwPwMUGICA5YAWLCEQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0654; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:DM2PR0301MB0654; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0654; x-forefront-prvs: 07954CC105 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(199003)(24454002)(106356001)(5001960100002)(189998001)(54356999)(76176999)(81156007)(99286002)(105586002)(110136002)(19580405001)(86612001)(86362001)(101416001)(97736004)(5003600100002)(50986999)(74316001)(66066001)(19580395003)(33656002)(76576001)(2950100001)(3846002)(11100500001)(87936001)(77096005)(8990500004)(10400500002)(40100003)(92566002)(5002640100001)(5004730100002)(2900100001)(5005710100001)(10090500001)(586003)(122556002)(6116002)(10290500002)(1096002)(102836003)(1220700001)(5008740100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0654; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2015 00:41:28.3513 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0654 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Do we really need two 0-RTT keys? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2015 00:41:33 -0000 T24gRnJpZGF5LCBEZWNlbWJlciAxOCwgMjAxNSAzOjAyIFBNLCBFcmljIFJlc2NvcmxhIHdyb3Rl Og0KPiBPbiBGcmksIERlYyAxOCwgMjAxNSBhdCAyOjQ1IFBNLCBDaHJpc3RpYW4gSHVpdGVtYSA8 aHVpdGVtYUBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4uLi4NCj4+IFRoZSB0ZXh0IGluZGljYXRl cyB0aGF0IGNsaWVudCBhdXRoIGFuZCBhcHBsaWNhdGlvbiBkYXRhIG1lc3NhZ2VzIGFyZSBwcm90 ZWN0ZWQgYnkgImtleXMgDQo+PiBkZXJpdmVkIGZyb20gdGhlIHN0YXRpYyBzZWNyZXQuIiBCdXQg dGhlbiwgaGlkZGVuIGluIHNlY3Rpb24gNy4yIGlzIGFuIGludGVyZXN0aW5nIHR3aXN0IC0tIA0K Pj4gdHdvIGRpZmZlcmVudCBrZXlzIGFyZSBzdXBwb3NlZCB0byBiZSBkZXJpdmVkIGZyb20gdGhl IHN0YXRpYyBzZWNyZXQsIG9uZSBmb3IgMC1SVFQgDQo+PiBoYW5kc2hha2UsIGFub3RoZXIgZm9y IDAtUlRUIEFwcGxpY2F0aW9uLiBJZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCB0aGUgQ2VydGlm aWNhdGUsDQo+PiBDZXJ0aWZpY2F0ZVZlcmlmeSBhbmQgQ2xpZW50IEZpbmlzaGVkIG1lc3NhZ2Ug d291bGQgYmUgcHJvdGVjdGVkIHdpdGggdGhlICIwLVJUVA0KPj4gSGFuZHNoYWtlIiBrZXksIGFu ZCB0aGUgQXBwbGljYXRpb24gZGF0YSBhbmQgZW5kLW9mLWVhcmx5IGRhdGEgbWVzc2FnZSB3b3Vs ZCANCj4+IGJlIHByb3RlY3RlZCB3aXRoIHRoZSAiMC1SVFQgQXBwbGljYXRpb24iIGtleS4NCj4N Cj4gWWVzLCB0aGF0J3MgY29ycmVjdC4NCj4NCj4+IEkgYXNzdW1lIHRoYXQgdGhlcmUgaXMgYSBn b29kIHJlYXNvbiBmb3IgdGhpcyBleHRyYSBjb21wbGV4aXR5LCBldmVuIGlmIGl0IGVsdWRlcyBt ZS4NCj4NCj4gVGhlIG1vdGl2YXRpb24gZm9yIHRoaXMgd2FzIHRoYXQgYSBudW1iZXIgb2YgcGVv cGxlIHdvcmtpbmcgb24gYW5hbHlzaXMgY29tcGxhaW5lZA0KPiB0aGF0IHVzaW5nIHRoZSBzYW1l IGtleSB0byBlbmNyeXB0IGhhbmRzaGFrZSB0cmFmZmljIGFuZCBhcHBsaWNhdGlvbiB0cmFmZmlj IChhcw0KPiBpcyBkb25lIGluIFRMUyAxLjIgd2l0aCBGaW5pc2hlZCBhbmQgYXBwbGljYXRpb24g bWVzc2FnZXMpIG1hZGUgYW5hbHlzaXMgaGFyZGVyLg0KPiBJJ20gbm90IGVxdWlwcGVkIHRvIHRh a2UgYSBwb3NpdGlvbiBvbiB0aGlzLCBidXQgdGhhdCdzIHdoYXQgSSBoYXZlIGJlZW4gdG9sZC4g V2UNCj4gYWxyZWFkeSBkbyB0aGF0IGZvciB0aGUgMS1SVFQga2V5cyBhbmQgd2UncmUgZG9pbmcg dGhlIHNhbWUgdGhpbmcgaGVyZS4NCg0KQWN0dWFsbHksIHdlIGRvIGJvdGguIEluIHNlY3Rpb24g Ni4yLjMsIHRoZSBkaWFncmFtIHNob3dzIFtOZXdTZXNzaW9uVGlja2V0XSBiZXR3ZWVuIHNxdWFy ZSBicmFja2V0cywgaS5lLiBlbmNyeXB0ZWQgd2l0aCB0aGUgc2FtZSBrZXkgYXMgQXBwbGljYXRp b24gRGF0YS4gV2hpY2ggbWFrZXMgc2Vuc2UsIGJlY2F1c2UgaXQgd2lsbCBiZSByZWNlaXZlZCBh ZnRlciB0aGUgU2VydmVyIEZpbmlzaGVkIG1lc3NhZ2UuIEkgYXNzdW1lIHRoZSBzYW1lIGlzIHRy dWUgZm9yIG90aGVyIFBvc3QgSGFuZHNoYWtlIG1lc3NhZ2VzLg0KwqANCj4+IEJ1dCBJIHdvcnJ5 IGEgYml0IGFib3V0IHdoYXQgdGhhdCB3b3VsZCBkbyB3aGVuIHdlIHN0YXJ0IHdvcmtpbmcgb24g RFRMUyAxLjMuIFVEUCANCj4+IG1lc3NhZ2VzIGNhbiBhcnJpdmUgb3V0IG9mIG9yZGVyLiBZZXMs IHRoZXJlIGlzIGEgbWVzc2FnZSBudW1iZXIsIGJ1dCB0aGUgcmVjb3JkIGxheWVyIA0KPj4gaXMg bm90IG5lY2Vzc2FyaWx5IHdlbGwgcG9zaXRpb25lZCB0byBpbnRlcnByZXQgaXQgLS0gdGhlIGNl cnRpZmljYXRlIGFuZCB2ZXJpZnkgbWVzc2FnZSANCj4+IGFyZSBvcHRpb25hbCwgc28gd2hlbiBh IHJlY29yZCBsYXllciByZWNlaXZlcyBwYWNrZXQgIzMgYmVmb3JlIHBhY2tldCAjMiwgaXQgZG9l cyBub3QgDQo+PiBrbm93IHdoZXRoZXIgdGhpcyBpcyBhIENlcnRpZmljYXRlVmVyaWZ5IG1lc3Nh Z2UgKGhhbmRzaGFrZSBrZXkpIG9yIGFuIGFwcGxpY2F0aW9uIA0KPj4gbWVzc2FnZSAoYXBwbGlj YXRpb24ga2V5KS4NCj4NCj4gTm90ZTogdGhlIENlcnRpZmljYXRlIG1lc3NhZ2UgaXNuJ3Qgb3B0 aW9uYWwgaW4gdGhlIHNlbnNlIHRoYXQgdGhlIHNlcnZlciBkb2Vzbid0DQo+IGtub3cgaWYgaXQn cyBjb21pbmcuIFdoZXRoZXIgaXQncyBzZW50IGlzIGNvbmRpdGlvbmVkIG9uIHRoZSBjb25maWd1 cmF0aW9uIChpbiBXSVAtMTEpDQo+IGFuIG9uIHRoZSBjbGllbnQncyBFYXJseURhdGFJbmZpY2F0 aW9uIChpbiBXSVAtMTApLg0KDQpZZXMsIEkgcmVhbGl6ZSB0aGF0LiBCdXQgaW4gdGhlb3J5IHdl IGhhdmUgYSAibGF5ZXJlZCBwcm90b2NvbC4iIFdoYXQgeW91IGRlc2NyaWJlIGlzIHNvbWV3aGF0 IG9mICBhIGxheWVyIHZpb2xhdGlvbi4NCg0KPiBCdXQgeW91ciBnZW5lcmFsIHBvaW50IGlzIHJp Z2h0IGluIHRoYXQgeW91IGNhbiBoYXZlIGxvc3MgYW5kIHJlb3JkZXJpbmcuIFNvLCBmb3IgaW5z dGFuY2UsDQo+IHNheSB0aGF0IHRoZSBjbGllbnQgc2VuZHMgbWVzc2FnZXMgd2l0aCBzZXEgbnVt cyBhcyBmb2xsb3dzOg0KPg0KPsKgIMKgIENsaWVudEhlbGxvOiAwIChpbiBjbGVhcikNCj7CoCDC oCBGaW5pc2hlZDogMSAod2l0aCBIYW5kc2hha2UgS2V5KQ0KPsKgIMKgIEFwcERhdGE6IMKgMiAo d2l0aCBhcHAga2V5KQ0KPg0KPsKgIMKgIE5vdywgMSBhbmQgMiBhcmUgbG9zdCwgYW5kIHRoZSBj bGllbnQgcmV0cmFuc21pdHM6DQo+DQo+wqAgwqAgRmluaXNoZWQ6IDMgKHdpdGggSGFuZHNoYWtl IEtleSnCoA0KPsKgIMKgIEFwcERhdGE6IDQgKHdpdGggYXBwIGtleSkNCj4NCj4gSWYgIzMgaXMg bm93IGxvc3QsIHRoZSBzZXJ2ZXIgbWF5IG5vdCBrbm93IGlmICM0IGlzIGhhbmRzaGFrZSBvciBh cHBsaWNhdGlvbiBkYXRhDQo+IHNpbmNlIChmb3IgaW5zdGFuY2UpIHRoZSBjbGllbnQgbWlnaHQg aGF2ZSBmcmFnbWVudGVkIHRoZSBGaW5pc2hlZCBvdmVyIHR3bw0KPiByZWNvcmRzLg0KPg0KPiBO b3csIEkgdGhpbmsgdGhlcmUgYXJlIHNldmVyYWwgd2F5cyB0byBkZWFsIHdpdGggdGhpcy4gRmly c3QsIHRoZSBzZXJ2ZXIgY2FuIGp1c3QNCj4gY29udGludWUgdG8gYXR0ZW1wdCB0byBwcm9jZXNz IHJlY29yZHMgd2l0aCB0aGUgaGFuZHNoYWtlIGtleSB1bnRpbCB0aGUgaGFuZHNoYWtlDQo+IGlz IGNvbXBsZXRlZCwgaW4gd2hpY2ggY2FzZSBpdCB3aWxsIGRyb3AgIzQgYW5kIHRoZW4gZ2V0IHRo ZSByZXRyYW5zbWl0IG9mIHRoZQ0KPiBGaW5pc2hlZCAoIzUsIHByZXN1bWFibHkpLiBTZWNvbmQs IERUTFMgaGFzIGFuIGVwb2NoICMgdXNlZCB0byBpbmRpY2F0ZSB3aGljaA0KPiBnZW5lcmF0aW9u IGtleSB5b3UgYXJlIHVzaW5nLiBXZSBzaG91bGQgY29tZSBkb3duIG9uIHNvbWUgZGV0ZXJtaW5p c3RpYyB1c2Ugb2YNCj4gdGhhdCBpbiB3aGljaCBjYXNlIHRoaW5ncyB3aWxsIGJlIG9idmlvdXMu DQoNClRoZSBvYnZpb3VzIHdvcmthcm91bmQgaXMgdG8gaGF2ZSBzZXZlcmFsIGtleXMgYXZhaWxh YmxlIGF0IHRoZSByZWNvcmQgbGF5ZXIsIGFuZCBpZiBvbmUgZmFpbHMgdHJ5IHRoZSBvdGhlci4g T2YgY291cnNlLCBpdCBvcGVucyB0aGUgZ2F0ZXMgZm9yIGludGVyZXN0aW5nIGJ1Z3MuLi4NCg0K Pj4gWWVzLCB0aGVyZSBhcmUgc29sdXRpb25zLCB5ZXMsIGl0IGNhbiBiZSBtYW5hZ2VkLCBidXQg YXJlIHdlIHN1cmUgdGhhdCB0aGlzIHBhcnRpY3VsYXIgYml0DQo+PiBvZiAgY29tcGxleGl0eSBp cyB3b3J0aCBpdD8NCj4NCj4gS2FydGhpaz8gT3RoZXJzPyA6KQ0KPg0KPj4gQW5kIGlmIGl0IHdv cnRoIGl0LCBjYW4gd2UgYWRkIGEgZGVzY3JpcHRpb24gb2YgdGhlIGtleSBzd2l0Y2hpbmcgbG9n aWMgaW4gc2VjdGlvbiA2LjIuMj8NCj4NCj4gVGhhdCBzZWVtcyBsaWtlIGEgZ29vZCBwbGFuLi4u DQoNClllcyBwbGVhc2UhDQoNCi0tIENocmlzdGlhbiBIdWl0ZW1hDQoNCg== From nobody Fri Dec 18 16:50:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69051A0178 for ; Fri, 18 Dec 2015 16:50:25 -0800 (PST) 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, HTML_MESSAGE=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 QmA0IVraTE_N for ; Fri, 18 Dec 2015 16:50:24 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D41F1A0174 for ; Fri, 18 Dec 2015 16:50:24 -0800 (PST) Received: by mail-yk0-x235.google.com with SMTP id v6so77427710ykc.2 for ; Fri, 18 Dec 2015 16:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NRU9zWaiQ9EoCJTvuopq8XCiIptgNsUC4B/51l5ESCU=; b=aeHLzAeBALvi6Wt5rwLmJHDBVQ7YzcT2wnuGSibkcd/aJKh1/HGbYqne+J1zL2OO37 Mk/id9CqxGjwUi+IIvNKtwqRCBwkMa3YhETSTlWme5gJczLtH5uu1T0OJZGoeVZmuGvm yMq0w3eqSzh7NiKaka2eH66TpwLEUt0hXns9eoJQFvGTDGsyi2OCtcEayC0OpKVPIaC1 CiqXAr6prI22aAYu4FtTO9DjmgeoefpKuhbqZDXeI0huCLpOPJFPYd6HGnotegZzDppJ 8g/KYCu9xhcmmHnK8D+B4SRSKvPMDhsAsFXZaWISenVH2mQLDeAGkFgPSN4xwrBgFSQo u8Dg== 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=NRU9zWaiQ9EoCJTvuopq8XCiIptgNsUC4B/51l5ESCU=; b=mj+f66j5kqU8Lu+opfYbOFF4RqnRPkEzs5F9dLvpxVzpi80pRTW1NHBi6IwO1ZimF0 3TOb+4JSu4wLoRVpGjPkn+1IJrxDMyPa7Y04ht8GjVM9ATmMPZdF8YP+Ik63XC8by29X 2hMjXQnlr+73oFFI0lPfHYxjJywEBlQC+Sfp3MDSVUXayLfH4ErdgWUgNw+bx56XV3tC XiRH59TpqGylq97+IQHNX5nGStgSQlecrdOBlD19KYRUMzaKstbGICjCmykLww7IASqk l1ly4PTt0JlaYptwiZ0kyhwBhVjXHBBpsUA0TevKJT1JiHRAOVcR3GvC9Nkly4u+mjJp k8uA== X-Gm-Message-State: ALoCoQmc2oTcZ0X1yDzBm98uUQ7hsLKUGamrVD9eCAXmAEclgUIWuO6HZf4wubw01g1IaNYw1NkiEdOkdco4FGAR6LzRhJgQMQ== X-Received: by 10.129.153.3 with SMTP id q3mr6210227ywg.231.1450486223504; Fri, 18 Dec 2015 16:50:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Fri, 18 Dec 2015 16:49:44 -0800 (PST) In-Reply-To: <7327a9142c2c41f39028d8882be8ae45@AM3PR30MB049.064d.mgd.msft.net> References: <5e85e3b1a1914ea8bbd5d985c321c119@AM3PR30MB049.064d.mgd.msft.net> <7327a9142c2c41f39028d8882be8ae45@AM3PR30MB049.064d.mgd.msft.net> From: Eric Rescorla Date: Fri, 18 Dec 2015 16:49:44 -0800 Message-ID: To: Cedric Fournet Content-Type: multipart/alternative; boundary=94eb2c0bbfae1abaed052735a4f5 Archived-At: Cc: Antoine Delignat-Lavaud , Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] [tls13-spec] resetting the sequence number to zero for each record key. (#379) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Dec 2015 00:50:26 -0000 --94eb2c0bbfae1abaed052735a4f5 Content-Type: text/plain; charset=UTF-8 Does anyone object to this change? If not, I intend to merge it in this weekend. -Ekr On Fri, Dec 18, 2015 at 7:47 AM, Cedric Fournet wrote: > The surprise is that breaking one key also yields the ability to truncate > traffic protected with another key. We agree that we don't have any > particularly scary way to exploit it against the current draft, but we'd > much prefer handshake encryption not to depend on 0RTT, and application > data protection not to depend on handshake encryption. > > With our proposed change, the main point to keep in mind is that, by > design, the TLS 1.3 record layer does not prevent suffix truncations. > Instead, TLS prevents prefix truncations at the protocol layer, by sending > an unambiguous final message with each record key: end_of_early_data; > finished; and close_notify. > > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: 17 December 2015 23:39 > To: Cedric Fournet > Cc: tls@ietf.org; Antoine Delignat-Lavaud ; > Karthikeyan Bhargavan > Subject: Re: [TLS] [tls13-spec] resetting the sequence number to zero for > each record key. (#379) > > So the actual impact here is that an attacker who has compromised a key > can introduce a gap. Aren't there other options available to such an > attacker? Scarier options? > > On 18 December 2015 at 07:01, Cedric Fournet > wrote: > > > > We propose to revert this change (that is, to reset the sequence > > number each time a new key is installed, as in TLS 1.2). If the > > chaining is still required for some other reason, one could instead > > include the old sequence number in the new key derivation (or the new > > key's additional data, but we believe this is no longer an option). > > Even with my question above, this seems reasonable to me. I'll note that > chaining in the way you describe would require that the rekey message (the > last message of the previous epoch) would need to be retransmitted in > DTLS. That seems more brittle, but we probably want to retransmit anyway, > since that would let use remove the explicit epoch from DTLS packets. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0bbfae1abaed052735a4f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Does anyone object to this change? If not, I intend to mer= ge it in this weekend.

-Ekr


On Fri, Dec 18, 201= 5 at 7:47 AM, Cedric Fournet <fournet@microsoft.com> wro= te:
The surprise is that breaking one key= also yields the ability to truncate traffic protected with another key. We= agree that we don't have any particularly scary way to exploit it agai= nst the current draft, but we'd much prefer handshake encryption not to= depend on 0RTT, and application data protection not to depend on handshake= encryption.

With our proposed change, the main point to keep in mind is that, by design= , the TLS 1.3 record layer does not prevent suffix truncations. Instead, TL= S prevents prefix truncations at the protocol layer, by sending an unambigu= ous final message with each record key:=C2=A0 end_of_early_data; finished; = and close_notify.

-----Original Message-----
From: Martin Thomson [mailto:ma= rtin.thomson@gmail.com]
Sent: 17 December 2015 23:39
To: Cedric Fournet <fournet@mic= rosoft.com>
Cc: tls@ietf.org; Antoine Delignat-Lava= ud <antdl@microsoft.com>; = Karthikeyan Bhargavan <ka= rthik.bhargavan@gmail.com>
Subject: Re: [TLS] [tls13-spec] resetting the sequence number to zero for e= ach record key. (#379)

So the actual impact here is that an attacker who has compromised a key can= introduce a gap.=C2=A0 Aren't there other options available to such an= attacker?=C2=A0 Scarier options?

On 18 December 2015 at 07:01, Cedric Fournet <fournet@microsoft.com> wrote:
>
> We propose to revert this change (that is, to reset the sequence
> number each time a new key is installed, as in TLS 1.2). If the
> chaining is still required for some other reason, one could instead > include the old sequence number in the new key derivation (or the new<= br> > key's additional data, but we believe this is no longer an option)= .

Even with my question above, this seems reasonable to me.=C2=A0 I'll no= te that chaining in the way you describe would require that the rekey messa= ge (the last message of the previous epoch) would need to be retransmitted = in DTLS.=C2=A0 That seems more brittle, but we probably want to retransmit = anyway, since that would let use remove the explicit epoch from DTLS packet= s.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--94eb2c0bbfae1abaed052735a4f5-- From nobody Sun Dec 20 12:54:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4684E1A011B for ; Sun, 20 Dec 2015 12:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 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, 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 2_xIVZcIvwb7 for ; Sun, 20 Dec 2015 12:54:28 -0800 (PST) Received: from mail-qg0-x241.google.com (mail-qg0-x241.google.com [IPv6:2607:f8b0:400d:c04::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04191A0115 for ; Sun, 20 Dec 2015 12:54:27 -0800 (PST) Received: by mail-qg0-x241.google.com with SMTP id 95so6125584qgm.3 for ; Sun, 20 Dec 2015 12:54:27 -0800 (PST) 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=HDDZNeTCHzYGfi7Z95vbF+1PUz7EgV8UHl0/pi/M+VM=; b=t0OHI4tueJJp3WWAMytvnKuVWKoSn+P29PC2RMi7rJmp+pVkYmVmGRL8xZfbdejfUU uXaBahwBzLhayIqSBUcVpJy6IwTQYo+KQE5F24m24ZQsyz8h6NJO6o/peYf3j3iSYs4m GUi2D+zHpMZsLqP/Iund+4RlGqAIx6xecVBxorUN7mXkLDIxOTSMEkXGfV2Z4ATn1ht3 FS5/bqvIjFCUb1SQBlHdefmXqMJLFm2Xeedr9Mr0nam5jN37JFFouFof1cbv3wUxlAqo PhRqw9gnuY8mvAvZN34T8RVc4FGupOSwPP7qHuZg9An8Mpt/JXwE8bk1BOduhAq4DdNo J8Ig== MIME-Version: 1.0 X-Received: by 10.140.162.214 with SMTP id i205mr21525239qhi.32.1450644867050; Sun, 20 Dec 2015 12:54:27 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.93.12 with HTTP; Sun, 20 Dec 2015 12:54:26 -0800 (PST) In-Reply-To: References: Date: Sun, 20 Dec 2015 12:54:26 -0800 X-Google-Sender-Auth: D0m91Q2wWBxbLhTANVWwhKdj7YY Message-ID: From: Adam Langley To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Dec 2015 20:54:29 -0000 On Fri, Dec 18, 2015 at 1:43 PM, Brian Smith wrote: >> The recent renaming of the ChaCha20-Poly1305 cipher suites brought >> something to my attention that I hadn't thought about before. It seems like >> it might be better to use HKDF-SHA512 instead of HKDF-SHA512, and > > > That is, it seems it would be better to use HKDF-SHA512 instead of > **HKDF-SHA256**. I assume that you mean for TLS 1.3 since you mention HKDF? I updated the draft recently because David Benjamin noted that the names didn't include the PRF (which they should these days) and that OpenSSL, at least, used SHA-256, so might as well make the spec match reality. So, the current code points are probably SHA-256 now. I don't object to adding more if people want SHA-384 too. Although, since the hash function is only used in key derivation with these cipher suites, I'm not sure that a slower, software implementation of SHA-256 would be a big problem. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Sun Dec 20 17:13:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02A51A711A for ; Sun, 20 Dec 2015 17:13:22 -0800 (PST) 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, 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 eui-qfhhbNeI for ; Sun, 20 Dec 2015 17:13:21 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0261A7113 for ; Sun, 20 Dec 2015 17:13:21 -0800 (PST) Received: by mail-ob0-x235.google.com with SMTP id ba1so21711919obb.3 for ; Sun, 20 Dec 2015 17:13:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x3IzB4QbNrAxeuc5u0GgGiZhHBxKJ1oyTJ1PKIICJG8=; b=Oogp1ZLE46+hXiaf01y3gS6iZLhsZieRQ7DvRKXDzyCdacDNikBt25vj9i7okusF6e aufnNNk/J+pUawXNKGiRTtjhWMGYlI0aC0GoqU+kobNAs9fNZqiJjnVLym71diUH/65r p5O5E1Q2KVZ2HEJIn47ORuix6+DJuRQODt77Fs57h5fcbg8lQj5vIIMwfVQpPb2/Fvu6 vqLAzuGIT6y/Z0ypgUbrePpfqRWk+2NFXiwtenNtKSFquJSK5Q54mwVuHEqmz7XAsbw/ nCo8gxb8L6SGGeqigp66sB390zKJq/6UavKfhlcNTxzA7wULg0iDjaPlHW+BEUgS7Eyc k3CQ== 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=x3IzB4QbNrAxeuc5u0GgGiZhHBxKJ1oyTJ1PKIICJG8=; b=MyDjsmelPW6VkNRMnmLdT8myB1S5KCuaOo1w14xV0LRJuOzw7TuuaCrVqKk0mdg791 /DikAd+XFMF/ysX7qM2QXh42qmKHSM72XDCgpyTW+55rSw4D5mh+iRFh1sVsEsXoUlai t28wVuzdgAqdHwgXNQtlaNpCXK8JDTmy1xXtpi1r+wNxVSTPMLVL/nMHmi9UOWPX/Yos u6LlR/NVRrurgm66AUQubNGGP5gg4wGOBsFjc+UaW5Lez8liba19sdZeljNEu7D14EiC 4R/Me8jjlxOf5dKnGr1gQQQYlS10dWdyPgDf7+niMVRxct+jFljT+Cn2sWYHgzk++eyu Lg3w== X-Gm-Message-State: ALoCoQnsbVIk9sISD5o6fK9puVkrCInSaarI7soc5cLGLjxzuOkRs+Q4viG+9Ay6LXK/5n6x5MyJP9dGpxfI1+810dCJqY67pw== MIME-Version: 1.0 X-Received: by 10.60.82.101 with SMTP id h5mr6171572oey.44.1450660400548; Sun, 20 Dec 2015 17:13:20 -0800 (PST) Received: by 10.76.62.8 with HTTP; Sun, 20 Dec 2015 17:13:20 -0800 (PST) In-Reply-To: References: Date: Sun, 20 Dec 2015 15:13:20 -1000 Message-ID: From: Brian Smith To: Adam Langley Content-Type: multipart/alternative; boundary=047d7b676d3edd67ac05275e31df Archived-At: Cc: "" Subject: Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Dec 2015 01:13:22 -0000 --047d7b676d3edd67ac05275e31df Content-Type: text/plain; charset=UTF-8 Adam Langley wrote: > On Fri, Dec 18, 2015 at 1:43 PM, Brian Smith wrote: > > That is, it seems it would be better to use HKDF-SHA512 instead of > > **HKDF-SHA256**. > > I assume that you mean for TLS 1.3 since you mention HKDF? No, I mean for all versions of TLS. > I updated > the draft recently because David Benjamin noted that the names didn't > include the PRF (which they should these days) and that OpenSSL, at > least, used SHA-256, so might as well make the spec match reality. > The version of OpenSSL that implements these cipher suites is not released yet. They updated that implementation just 9 days ago, so it seems pretty malleable still. > So, the current code points are probably SHA-256 now. I don't object > to adding more if people want SHA-384 too. Although, since the hash > function is only used in key derivation with these cipher suites, I don't think it would be a good idea to add more code points to negotiate SHA-512 in the PRF while still leaving code points for negotiating SHA-256 in the PRF. It should be one or the other. > I'm > not sure that a slower, software implementation of SHA-256 would be a > big problem. It just seems really unfortunate to mandate SHA-512 for Ed25519 and then mandate SHA-256 for ChaCha20-Poly1305 in TLS. Mandating the same algorithm for both seems like a better idea. Cheers, Brian -- https://briansmith.org/ --047d7b676d3edd67ac05275e31df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adam= Langley <agl@imperialviolet.org> wrote:
On Fri, Dec 18, 2015 at 1:43 PM, Brian Smith <brian@briansmith.org> wrote:> That is, it seems it would be better to use HKDF-SHA512 instead of > **HKDF-SHA256**.

I assume that you mean for TLS 1.3 since you mention HKDF?

No, I mean for all versions of TLS.
=C2=A0=
I updated
the draft recently because David Benjamin noted that the names didn't include the PRF (which they should these days) and that OpenSSL, at
least, used SHA-256, so might as well make the spec match reality.

The version of OpenSSL that implements these ci= pher suites is not released yet. They updated that =C2=A0implementation jus= t 9 days ago, so it seems pretty malleable still.=C2=A0
=C2=A0
So, the current code points are probably SHA-256 now. I= don't object
to adding more if people want SHA-384 too. Although, since the hash
function is only used in key derivation with these cipher suites,

I don't think it would be a good idea to ad= d more code points to negotiate SHA-512 in the PRF while still leaving code= points for negotiating SHA-256 in the PRF. It should be one or the other.<= /div>
=C2=A0
I'm
not sure that a slower, software implementation of SHA-256 would be a
big problem.

It just seems really unfortuna= te to mandate SHA-512 for Ed25519 and then mandate SHA-256 for ChaCha20-Pol= y1305 in TLS. Mandating the same algorithm for both seems like a better ide= a.

Cheers,
Brian
--
<= div class=3D"gmail_signature">
<= div dir=3D"ltr">

--047d7b676d3edd67ac05275e31df-- From nobody Sun Dec 20 17:42:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A58F1A016A for ; Sun, 20 Dec 2015 17:42:13 -0800 (PST) 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, HTML_MESSAGE=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 ZxCIUIuv8KPf for ; Sun, 20 Dec 2015 17:42:12 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425601A0110 for ; Sun, 20 Dec 2015 17:42:12 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id 140so117051296ykp.0 for ; Sun, 20 Dec 2015 17:42:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jatP1gqXFCLigm5thvehCdPoVYuLb7qPT810VELLP+M=; b=F43k+ISiyX7TU97PzFuIXzpFSlOXY3GIeKZLR1668C14U4mCKeOmOvqeu9OsTc5xBY beoRpZ3i9uGghVp6tJ6RFfeHPSsdnsLn3Mj7dKoAUuSugBL61Wc8i6+E8Q7PhtfhqXZH 3HHx3usInn56S101BNk1MGm8csvLXpmqCdikuj5RPwnUVQmSYMYafBRWiHDYbsZ1PP5Q Wt+xJ0CGLqERK4hZLhiccaei1Z7K3pC2+MGmMk5cPL+jNczqRya9oC2s2bFdZswlIU55 2KBr00Q9wkJ9RkS5yp+HsggTNh8AU3LYyFGE3Xu81HWuYbKclpdoB0MMwaCEuy63SnkT tl7Q== 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=jatP1gqXFCLigm5thvehCdPoVYuLb7qPT810VELLP+M=; b=mqshSMw6406uqX4BaIRjja/ZGZcLRrN+P+8b+aJT2eQoYbuLK6ikNQHAQHWlCwct3X BUdoqKqWEWzkGRxyNmcZ6va1VGYNGlc3USCyle6sgpU0DX/cC2gDwDaJfi8nZrzUAyva DblcZOzOrDZGveEzxAWpf/ruOvgHYyymPAwIa+RkwEJcl7pG8NJ8yA8hCVDQj3RPE84u 8DTn0N03DDpADm7DVFKOBdXUcj4YWB9bqLRS7ZBCgvkMVI4SPC+ykgTIQVz4t8fAgRuK OpJzChI+Qy1kgNFs/BZhL9NCUwKqQk+B+OB+fKhcI1CAZ3XyM1+V1h5B4t9w1oOrO1Wv 3akQ== X-Gm-Message-State: ALoCoQmnoYEwxJ3R6ZCRT8Y8+vuebF+rugcUJs0zWgBK/8S9zrZERRWwAlEYrLFDyam0sQ9Enc+D//noldTPeMZJSojMyLhS1Q== X-Received: by 10.129.79.87 with SMTP id d84mr12443613ywb.115.1450662131549; Sun, 20 Dec 2015 17:42:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Sun, 20 Dec 2015 17:41:32 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sun, 20 Dec 2015 17:41:32 -0800 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=001a114dc3600a7ada05275e99a4 Archived-At: Cc: Adam Langley , "" Subject: Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Dec 2015 01:42:13 -0000 --001a114dc3600a7ada05275e99a4 Content-Type: text/plain; charset=UTF-8 On Sun, Dec 20, 2015 at 5:13 PM, Brian Smith wrote: > Adam Langley wrote: > >> On Fri, Dec 18, 2015 at 1:43 PM, Brian Smith >> wrote: >> > That is, it seems it would be better to use HKDF-SHA512 instead of >> > **HKDF-SHA256**. >> >> I assume that you mean for TLS 1.3 since you mention HKDF? > > > No, I mean for all versions of TLS. > Do you mean using SHA-512 in the TLS 1.2 PRF? Or something else? > So, the current code points are probably SHA-256 now. I don't object >> to adding more if people want SHA-384 too. Although, since the hash >> function is only used in key derivation with these cipher suites, > > > I don't think it would be a good idea to add more code points to negotiate > SHA-512 in the PRF while still leaving code points for negotiating SHA-256 > in the PRF. It should be one or the other. > > >> I'm >> not sure that a slower, software implementation of SHA-256 would be a >> big problem. > > > It just seems really unfortunate to mandate SHA-512 for Ed25519 and then > mandate SHA-256 for ChaCha20-Poly1305 in TLS. Mandating the same algorithm > for both seems like a better idea. > Can you explain what resource you're trying to conserve here? The MTI cipher suites for TLS 1.2 and 1.3 require SHA-256 and All the AES-GCM ciphers already require SHA-256 or SHA-384, so it seems like the vast majority of implementations are going to require at least one of these algorithms in any case. -Ekr --001a114dc3600a7ada05275e99a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sun, Dec 20, 2015 at 5:13 PM, Brian Smith <brian@briansmith.org= > wrote:
Adam Langley <agl@im= perialviolet.org> wrote:
On Fri, Dec 18, 2015 at 1:43 PM, Brian Smith <brian@briansmith.org> wrote:<= br>> That is, it seems it would be better to use= HKDF-SHA512 instead of
> **HKDF-SHA256**.

I assume that you mean for TLS 1.3 since you= mention HKDF?

No, I mean for all ve= rsions of TLS.

Do y= ou mean using SHA-512 in the TLS 1.2 PRF? Or something else?

=
=C2=A0
So, the current code points are probably SHA-256 now. I don't = object
to adding more if people want SHA-384 too. Although, since the hash
function is only used in key derivation with these cipher suites,

I don't think it would be a good ide= a to add more code points to negotiate SHA-512 in the PRF while still leavi= ng code points for negotiating SHA-256 in the PRF. It should be one or the = other.
=C2=A0
I'= m
not sure that a slower, software implementation of SHA-256 would be a
big problem.

It just seems really un= fortunate to mandate SHA-512 for Ed25519 and then mandate SHA-256 for ChaCh= a20-Poly1305 in TLS. Mandating the same algorithm for both seems like a bet= ter idea.

Can you e= xplain what resource you're trying to conserve here?

The MTI cipher suites for TLS 1.2 and 1.3 require SHA-256 and=C2=A0<= /div>
All the AES-GCM ciphers already require SHA-256 or SHA-384, so it=
seems like the vast majority of implementations are going to req= uire at
least one of these algorithms in any case.

=
-Ekr

=C2=A0
--001a114dc3600a7ada05275e99a4-- From nobody Sun Dec 20 17:50:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A9A1A8726 for ; Sun, 20 Dec 2015 17:50:04 -0800 (PST) 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, 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 0rLC97jLaqW1 for ; Sun, 20 Dec 2015 17:50:03 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E32F01A8724 for ; Sun, 20 Dec 2015 17:50:02 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id o124so85016927oia.1 for ; Sun, 20 Dec 2015 17:50:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QHvXwhjpK8v3jocNF2kI7R/1k4oXFq+cUYwSJRwjz9g=; b=Ev3fIBjNOQ84iqsHWysO+LGeXM6T0AGq5zC0HMO0/RnwslBkuRJvCcqJZ3RxloXHOd BQBtH4m1KcZtS0mKGQpmnYUtSsrBYOlj1mFZURCrlsEIkFr2vD8mTug8Lh6xKYiLucge MZbnRFh5Fo4sMjudE6cT9vPFzAu5M+glPOMwmD/TCPR2DgYe2jC61vt6GvQ8ni0WrzVk 9sv/U2INv4IxJ9qgc5yXF/P9ZaRiAk9gNodRiX8HH5kqzRAkVvPNreCxLQRQ3u9kEIr5 yYyhR3LOirxgWLa3uHc9512T5YIlO1L1XoXYPOfYbsyZE/9YaK8XYp/n8MPk7QJ/hW8v OX7A== 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=QHvXwhjpK8v3jocNF2kI7R/1k4oXFq+cUYwSJRwjz9g=; b=NOCRVFESfzIceg886rtFlnfK0i8RPE8ScTWZW7lhSWrtbxCu672A5l2LRJceW5oSM2 /iOV3IGY9fWizm6ulBzo/dR1LdbADMeRkY2PzH9aKxyX++4rOkMx92weO0903O1wqCTG Wvdv9WVvTV5t6zmvHCImWPkkLhaGf2XKMr6M7BCBhDrWA5OTS4FLyO5HlzPiWk02OWC3 1lYjSB9o70RiwzFE9tdneayTXlGg8g8mciaK9HUI47XQzSLDXduDqVMc3daFSqm9mQYP gpVub4FfKBXKBBb8lNW76t7k3vUTcljBmCTtjQR2RU+6TFHdME83F988GJpyzgnOzgS1 5nOw== X-Gm-Message-State: ALoCoQlf8G50JET6FBuQ++gfZfFPB6EQAtWvVtg8bZPLgyERiYbO2vV0CcI6FXFWIQ+ni6iE7Aos3Blsw4JIjNXjhbxBM/TeIg== MIME-Version: 1.0 X-Received: by 10.202.90.66 with SMTP id o63mr6041943oib.129.1450662601510; Sun, 20 Dec 2015 17:50:01 -0800 (PST) Received: by 10.76.62.8 with HTTP; Sun, 20 Dec 2015 17:50:01 -0800 (PST) In-Reply-To: References: Date: Sun, 20 Dec 2015 15:50:01 -1000 Message-ID: From: Brian Smith To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113d5da80d666405275eb55a Archived-At: Cc: Adam Langley , "" Subject: Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Dec 2015 01:50:04 -0000 --001a113d5da80d666405275eb55a Content-Type: text/plain; charset=UTF-8 Eric Rescorla wrote: > On Sun, Dec 20, 2015 at 5:13 PM, Brian Smith wrote: > >> Adam Langley wrote: >> >>> On Fri, Dec 18, 2015 at 1:43 PM, Brian Smith >>> wrote: >>> > That is, it seems it would be better to use HKDF-SHA512 instead of >>> > **HKDF-SHA256**. >>> >>> I assume that you mean for TLS 1.3 since you mention HKDF? >> >> >> No, I mean for all versions of TLS. >> > > Do you mean using SHA-512 in the TLS 1.2 PRF? Or something else? > Yes, for TLS 1.2 and TLS 1.3. > The MTI cipher suites for TLS 1.2 and 1.3 require SHA-256 and > All the AES-GCM ciphers already require SHA-256 or SHA-384, so it > seems like the vast majority of implementations are going to require at > least one of these algorithms in any case. > Nobody should pay attention to what the MTI cipher suite for TLS 1.2 is, because it's obsolete; in fact, one would be making a huge mistake to deploy it now if one's application didn't have legacy backward compatibility concerns. And, we should change the MTI cipher suite for TLS 1.3 to the ChaCha20-Poly1305 ones, because they solve a lot of problems. For example, they remove any question of any need to implement rekeying, they avoid the weird IV construction hacks that are necessary for 128-bit cipher suites like AES-GCM, and they can be implemented efficiently in a safe way, unlike AES-GCM. Cheers, Brian -- https://briansmith.org/ --001a113d5da80d666405275eb55a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Eric= Rescorla <ekr@rtfm.com> wrote:
= On Sun, Dec 20, 2015 at 5:13 PM, Brian Smith <brian@briansmith.org= > wrote:
Adam Langley <agl@imperialviolet.o= rg> wrote:
On Fri, Dec 18, 20= 15 at 1:43 PM, Brian Smith <brian@briansmith.org> wrote:
> That= is, it seems it would be better to use HKDF-SHA512 instead of
> **HKDF-SHA256**.

I assume that you mean for TLS 1.3 since you mention HK= DF?

No, I mean for all versions of T= LS.

Do you m= ean using SHA-512 in the TLS 1.2 PRF? Or something else?
<= /div>

Yes, for TLS 1.2 and TLS 1.3.
=C2=A0
The MTI cipher suites for= TLS 1.2 and 1.3 require SHA-256 and=C2=A0
All the AES= -GCM ciphers already require SHA-256 or SHA-384, so it
seems like= the vast majority of implementations are going to require at
lea= st one of these algorithms in any case.

Nobody should pay attention to what the MTI cipher sui= te for TLS 1.2 is, because it's obsolete; in fact, one would be making = a huge mistake to deploy it now if one's application didn't have le= gacy backward compatibility concerns. And, we should change the MTI cipher = suite for TLS 1.3 to the ChaCha20-Poly1305 ones, because they solve a lot o= f problems. For example, they remove any question of any need to implement = rekeying, they avoid the weird IV construction hacks that are necessary for= 128-bit cipher suites like AES-GCM, and they can be implemented efficientl= y in a safe way, unlike AES-GCM.

Cheers,
Brian
--
--001a113d5da80d666405275eb55a-- From nobody Sun Dec 20 18:10:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4931A8755 for ; Sun, 20 Dec 2015 18:10:01 -0800 (PST) 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, HTML_MESSAGE=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 o5XT9CyAbkuW for ; Sun, 20 Dec 2015 18:10:00 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B922D1A8759 for ; Sun, 20 Dec 2015 18:09:59 -0800 (PST) Received: by mail-yk0-x22c.google.com with SMTP id 140so117468933ykp.0 for ; Sun, 20 Dec 2015 18:09:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vly9pFjhHXBD+VCJNzd9hsjN1H3yMVAQfoEqoBxzGVQ=; b=wd1zErN298YnaeRZmyTQWH7uCfe1yWLQ/qyvDZCv/+jWn2gsgQGAP8HoALeB+KMPfQ nwptoeMLJMRQ88ZIyjm4B0GyqXuVdq5JG5JL5F2lVNuCQ7zrVbITw5BTkvoLB/p1N7RE bIV2WGhznWW0nQd7HytssLOR4ZAsm65rrO2WO17tDiixEXp7l6YlOcyQiqAVKeXn56OY iSNJ3ad221DpqvqpB9aQUzVpRxQdOgcvNsbz8gY71sZJ7/VdrBoOQ9SIRUWUBUGMC0QO fDDhZoKjgQI0s76ZTyhjqzJkZIICOoSFkZb3TumbJHePAZDsmTu8muel342UkBxOs+ws Mqlg== 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=vly9pFjhHXBD+VCJNzd9hsjN1H3yMVAQfoEqoBxzGVQ=; b=LYGolEew8lOz/xslYeleqzLGzOi4Mx3uNqq1zVsqOm1YpQJHBs+5H5yH7GgS8Dh+PO 8BgonHNXUKnVcuCysHbyagTi0v1jW4aeFDy27Xwuv+84XxXqOLtHL0hDyn/ttLJh46Cc TtiLs7tbEC/T/POVh9IdGiIrKgxYkarxn8OGvaZwEE4O9IGUCAB/E5whKaFUJVp59qMm QroC8Z7ye+EROAbeBnEReu7pVMRs7IQ4lEjdQn3ZB0Ev39jE0SBT1w7ki/OOhIlSQSxj gTNdxjqPF4JmgYEOjYALTyh/PD+Ru4HIo9jrP6PpAtclPofb+/CG5ybcZOB70LXAUdBM GaQw== X-Gm-Message-State: ALoCoQn50fnr0n89MUUAwMAejegl20/1fOZjhWcOMOkjuWsWiZpnaBu+v8qQkydGrQwN3MWmzrrDUdaS0h/AZhXNotabhoQDNw== X-Received: by 10.129.148.3 with SMTP id l3mr12878765ywg.155.1450663799055; Sun, 20 Dec 2015 18:09:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Sun, 20 Dec 2015 18:09:19 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sun, 20 Dec 2015 18:09:19 -0800 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=94eb2c07c8bc6e99d305275efcaf Archived-At: Cc: Adam Langley , "" Subject: Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Dec 2015 02:10:01 -0000 --94eb2c07c8bc6e99d305275efcaf Content-Type: text/plain; charset=UTF-8 On Sun, Dec 20, 2015 at 5:50 PM, Brian Smith wrote: > Eric Rescorla wrote: > >> On Sun, Dec 20, 2015 at 5:13 PM, Brian Smith >> wrote: >> >>> Adam Langley wrote: >>> >>>> On Fri, Dec 18, 2015 at 1:43 PM, Brian Smith >>>> wrote: >>>> > That is, it seems it would be better to use HKDF-SHA512 instead of >>>> > **HKDF-SHA256**. >>>> >>>> I assume that you mean for TLS 1.3 since you mention HKDF? >>> >>> >>> No, I mean for all versions of TLS. >>> >> >> Do you mean using SHA-512 in the TLS 1.2 PRF? Or something else? >> > > Yes, for TLS 1.2 and TLS 1.3. > Sorry, I'm still confused TLS 1.2 uses a specific PRF. TLS 1.3 uses HKDF. Are you suggesting TLS 1.2 use the TLS 1.2 PRF with SHA-512 and that TLS 1.2 use SHA-512 with HKDF, or something different? > The MTI cipher suites for TLS 1.2 and 1.3 require SHA-256 and >> All the AES-GCM ciphers already require SHA-256 or SHA-384, so it >> seems like the vast majority of implementations are going to require at >> least one of these algorithms in any case. >> > > Nobody should pay attention to what the MTI cipher suite for TLS 1.2 is, > because it's obsolete; in fact, one would be making a huge mistake to > deploy it now if one's application didn't have legacy backward > compatibility concerns. And, we should change the MTI cipher suite for TLS > 1.3 to the ChaCha20-Poly1305 ones, because they solve a lot of problems. > For example, they remove any question of any need to implement rekeying, > they avoid the weird IV construction hacks that are necessary for 128-bit > cipher suites like AES-GCM, and they can be implemented efficiently in a > safe way, unlike AES-GCM. > This seems like a separate question. SHA-256-using cipher suites are widely deployed and not going away any time soon, so what resource are you trying to conserve here? -Ekr --94eb2c07c8bc6e99d305275efcaf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Dec 20, 2015 at 5:50 PM, Brian Smith <brian@briansmith.org<= /a>> wrote:
Eric R= escorla <ekr@rtfm.com> wrote:
On Sun, Dec 2= 0, 2015 at 5:13 PM, Brian Smith <brian@briansmith.org> wr= ote:
Adam Langley <agl@imperialviolet.org> wrote:
On Fri, Dec 18, 2015 at 1:43 PM,= Brian Smith <= brian@briansmith.org> wrote:
> That is, it seems = it would be better to use HKDF-SHA512 instead of
> **HKDF-SHA256**.

I assume that you mean for TLS 1.3 since you mention HK= DF?

No, I mean for all versions of T= LS.

Do you m= ean using SHA-512 in the TLS 1.2 PRF? Or something else?
<= /div>

Yes, for TLS 1.2 and TLS 1.3.<= /div>

Sorry, I'm stil= l confused TLS 1.2 uses a specific PRF. TLS 1.3 uses HKDF.
Are yo= u suggesting TLS 1.2 use the TLS 1.2 PRF with SHA-512 and that
TL= S 1.2 use SHA-512 with HKDF, or something different?

=C2=A0
The MTI cipher suites for TLS 1.2 and 1.3 require SHA-256 and= =C2=A0
All the AES-GCM ciphers already require SHA-256= or SHA-384, so it
seems like the vast majority of implementation= s are going to require at
least one of these algorithms in any ca= se.

Nobody s= hould pay attention to what the MTI cipher suite for TLS 1.2 is, because it= 's obsolete; in fact, one would be making a huge mistake to deploy it n= ow if one's application didn't have legacy backward compatibility c= oncerns. And, we should change the MTI cipher suite for TLS 1.3 to the ChaC= ha20-Poly1305 ones, because they solve a lot of problems. For example, they= remove any question of any need to implement rekeying, they avoid the weir= d IV construction hacks that are necessary for 128-bit cipher suites like A= ES-GCM, and they can be implemented efficiently in a safe way, unlike AES-G= CM.

This seems like= a separate question.

SHA-256-using cipher suites = are widely deployed and not going away any time soon,
so what res= ource are you trying to conserve here?

-Ekr
<= div>
--94eb2c07c8bc6e99d305275efcaf-- From nobody Mon Dec 21 04:41:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991EC1A1A2C for ; Mon, 21 Dec 2015 04:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-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 zWB3cA2L9IaA for ; Mon, 21 Dec 2015 04:41:44 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45BF41A1A28 for ; Mon, 21 Dec 2015 04:41:44 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id DA32242E5C7; Mon, 21 Dec 2015 12:41:43 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-113.brq.redhat.com [10.34.0.113]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBLCfgTh020203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2015 07:41:43 -0500 From: Hubert Kario To: tls@ietf.org Date: Mon, 21 Dec 2015 13:41:35 +0100 Message-ID: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.6-201.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3516543.47rJPITsM8"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Subject: Re: [TLS] Data volume 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: Mon, 21 Dec 2015 12:41:45 -0000 --nextPart3516543.47rJPITsM8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 15 December 2015 20:01:58 Bill Frantz wrote: > So we have to trade off the risks of too much data vs. the risks > of a complex rekey protocol vs. the risks having the big data > applications build new connections every 2**36 or so bytes. >=20 > If we don't have rekeying, then the big data applications are > the only ones at risk. If we do, it may be a wedge which can > compromise all users. if the rekey doesn't allow the application to change authentication=20 tokens (as it now stands), then rekey is much more secure than=20 renegotiation was in TLS <=3D 1.2 so if we include rekeying in TLS, I'd suggest to set its limit to=20 something fairly low for dig data transfers, that is gigabytes, not=20 terabytes, otherwise we'll be introducing code that is simply not teste= d=20 for interoperability (with AES-NI you can easily transfer gigabytes in just few minutes) =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart3516543.47rJPITsM8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJWd/N/AAoJEJKo0bgB0vX1nHcP/j60J1Jvcm1zKsZXY9U1JCtv 9mgDg98d3SWN5Xd+7rIr51vrcMzuk1KWfWBjs8mb73+nJFAIJeV2NIaVeVHFK0Gt 1LziGuchJpFf5cLYnPpkDFTv4x9XP81Q16o41MHUrUK0oWwwHf9Plg9i4LzBgi3I FSNhy4gLWQiQQz00P1f6dm3bIxIdOxmeUz/6+iPJ1PMqZgzIv/66xnq5dktXfVYl 9tI7jB78tPIMZHObSXKjsiqF25DRz3jW9H7SYUXCsPUFMslDtD7SOmk3AH3SkCS1 ar3kU7bBobMeCrVzxkn7O8JK+YT0eI8bQWruMEGxu7ljo2FRkNCqgDOd5H+ZhteO hsJDdGkq8yEsxE+lMcxBtlnDukkVzFs3s3P28BeQFzPIi3RezRNI/r68zBWaxLR2 91nG5Vae5HL0CUEIeI383SKX9tANJM3OUqJfKZpGmwbQU4PmbGGNGkPZ/n6hBZsn mLkXQnV++CFIUETD0sHeKySMhaNgYHh7at5fPUVi54uHYXIKHjdx7cLrbKrD8zvI vUx+J9yts4Y94ytYLPypLZp+b+hCloPkwF45vR526TzJUZMvNL4xio4zfI7zzbFE NfUQq43ZJmrY3ipAZZn+wRrvkeg3zB6Ip1hdwFEZAcucIBXH6NgX+//JaXJtth6T ypOBBM9GXJa76/AX1Wao =LIxf -----END PGP SIGNATURE----- --nextPart3516543.47rJPITsM8-- From nobody Mon Dec 21 11:35:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510871AC416 for ; Mon, 21 Dec 2015 11:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 wBGD3D5Ry4yz for ; Mon, 21 Dec 2015 11:35:15 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 983CA1AC417 for ; Mon, 21 Dec 2015 11:35:14 -0800 (PST) Received: from [192.168.10.142] ([80.92.114.181]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M0xbD-1aSV3i2OUx-00v8Nl; Mon, 21 Dec 2015 20:35:10 +0100 To: Stephen Farrell , "tls@ietf.org" References: <564F2B3D.9000901@cs.tcd.ie> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <5678546F.5060202@gmx.net> Date: Mon, 21 Dec 2015 20:35:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <564F2B3D.9000901@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sbs2XAI29fI3PrqKPkwfsBinJLElEH0c1" X-Provags-ID: V03:K0:BClusRdVLxWLGJTvltKtw2pPteMYldHa7JXQ9v1+jPpRiBZ2u/9 yWvzpQnSSRyWsmKkeDpHnylNPpZBZZ1HZ8954TSRersX1+XJFRfYo1tbY94Y9cQju0fXf1A a+YWdnyoN5HK9aVWeX2XiZX/8jX1k1+JUCxIQaEvM1vF5uuAaDCHpK0541vvv3p+duDtoFh 5N5XcR1Spgbs5yblJssuQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:UlU+3G5+AdQ=:ihxvmv6mwBWdlzSVsJc8g8 2ajqNuePhvaNT//8urkrueUaU999dmxcWJhMw+wpAb3Vo7664tTZ3994R8UNuvhnoyPOJE8/a fmVmEKaRa+1QtruDgCp06w4OhAwtRF0p+M5EqgGVlh5pAvLQN1gczuVJEmyQNEMbiUN45IKRX XOdIRGUUx4lWQdhP35sWMc/vmiDbC04c5eLviwloZm6zXIt6K0BIHlamCfK6qrmQQAA6Jb029 I4xBrfqVbPVNa+bG8aVtnIu8IMeIUtZehgRsvzn9pHt5Ly9F2lzIYSiCMyXgJ9DQJivyNuLkt pNxZKyuswPqE9Ip47CepN2jjoKps0BihXIYYPoitJ7dbpzFryk1MyOV66G5dMcxH7gxC5jywq vyQMMo9MhnZMWrjOWhXTY1uAginY2g/99vI1SfCsux/naMnY/4vc+/NZ4SqIF6Yx+R/yMWiSR +Pj/Osxlf9nCxGd+pgljcO9VY2n813EAKMBOICaWZJd+kTriPAS6EJJHcJ0UcEzE4XI0nrZbc M5hkhnTFoaHIWNGxRNxum0wY3C3yuHBx0NmSlC10y2wEKwc/FJazLtoMA+AWNHHb/W1VkFHAg 25RaPaL9b8U9Hicwujil//CozHPe4lVNMmyVDQvOkA/uedNhoRhw3WELdSNvM+PoENKmN6MYt 9fBc2n9Kz6W3QwhGI0I+4xIK+hDo26xvCGKWJlNWIRfqK7sV4Xml7/KZFdLJl1W6qjZYxriKl G2eIC5qh5kNDwSUz6KDsJeqiLGH+zLPf86rUjNgwvr0vP3RcWAWuqshmz1w= Archived-At: Subject: Re: [TLS] AD review of /draft-ietf-tls-cached-info-20 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Dec 2015 19:35:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sbs2XAI29fI3PrqKPkwfsBinJLElEH0c1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Stephen, thanks for your review comments. On 11/20/2015 03:16 PM, Stephen Farrell wrote: >=20 > Hiya, >=20 > I've requested IETF LC for this one. (Sorry for being slow > getting to it.) Please treat my comments below along with > any other last call comments. >=20 > - You probably thought about this but I forget the argument. > Wouldn't it have been better to include the cached info that is not > sent within the transcript? I can't see an attack myself, but then > we didn't get the triple-handshake problem even after the initial > double-handshake attack was known. You are actually describing the problem we were having: We had both versions throughout the history of the document. There is this feeling that there could be an attack (somehow) but nobody knows how it works and so it is hard to decide for one or the other approach. > - ID nits complains that 6234 has obsoleted 4634, and indeed so it > has:-) I'll note that in the LC announce. Ok. >=20 > - 2^16-1 CachedObject instances makes no sense at all, that would be > bigger than the full handshake. Why not pick a sensible value? Even > if you don't put such a value in the syntax, you could at least say > that e.g. N instances will likely be pointless, for whatever N > (10-ish?) would make the h/w bigger overall. That's indeed a bit large. I reduced it to 1..2^8-1. >=20 > - page 6: wrt 7250 do you need to say that the server can tell which > thing (cert or SPKI) the client has cached from the hash value? I > think it can only work that way, but it might be worth saying that. > If it works some other way, then I didn't get that, so probably some > other bit of text would be needed. I added a note. I do indeed assume that the server is able to select the right certificate/SPKI from the received hash value. > - typo: consideratios Ok. Ciao Hannes >=20 > Cheers, > S. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --sbs2XAI29fI3PrqKPkwfsBinJLElEH0c1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWeFRwAAoJEGhJURNOOiAtG4sH/2aAkFGpUeuL6N3iJnb2hoAy mbdsUcfsAJoKzjgThtzwZgwBIrj+bvi/FZth57lwByvzsNaXdzbEWYEnTGs5mSEE Dh5sBszi0UHrVW6KICVLFi6tQcoqc1tvwn/jmtuk2liDZsiQCfpE5VCi0fdSgigq eoEl9LowroEUNzuFmIZz6QHQtMS4JVi/wXVw/grSYtkkoG6IDA+QpldU/7L+/MKF t+P0jxT7KUwNXHro4F1LqERqWTUkjYOaSUamzrCQ6ocmKc4d5OkfSDtRwtvQ9oA9 5O4q2GeiDKG5tLsOwbpkyMSdPDdye61h6iTGq1FkIpFMPPOmspIaFCS8S2LTwSU= =82/9 -----END PGP SIGNATURE----- --sbs2XAI29fI3PrqKPkwfsBinJLElEH0c1-- From nobody Mon Dec 21 16:54:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1041ACDDD for ; Mon, 21 Dec 2015 16:54:25 -0800 (PST) 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, 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 lZ2RePWGSS8h for ; Mon, 21 Dec 2015 16:54:24 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62821ACDD5 for ; Mon, 21 Dec 2015 16:54:23 -0800 (PST) Received: by mail-oi0-x229.google.com with SMTP id o124so100491488oia.1 for ; Mon, 21 Dec 2015 16:54:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Szk4x+hWMMMb5jBs+eQqTQ23zurQrfr1vcK9KaIetCY=; b=W6/0Z0+aeZ/4wKE/FR1MgxOFxoiWfuH/h92FktLxgRTqERjKelvL9Nu5W4YpBaurJ6 8+CInEplSQUH5J6zcv5HG8PYJu6bYrG5MxqxB2piHd+E1TjL79qK+li6AsEfew2mK3NF eG2K0LAZjMDQiAC0GNtkJ3qYpcQMVFhOArpzxnNo6S5OIRCbJZDUUX/QjDWv3uHCh0MC VQeVUReTDmGXgQRHBxMOLzJUUtGUL0h63RV6MRTE67LdiIesqSv1kqW2rBDz5QnxZHpk Ve4MZaTqZu/I53eXgXwgnoxHgSpLdnaoIsUsHd1Oh23r9sfif8oA5607iE7luKCAfbI0 fyPg== 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=Szk4x+hWMMMb5jBs+eQqTQ23zurQrfr1vcK9KaIetCY=; b=La1bt3QD0yOgc4ulZH1fNDa0DQo2PRLqZOa7pfJgiGAqDiYRKtw1Ak5TqsdEQemqqe 2A0h9Vls+0/oZGycRn1DDsrgTmEFFsfaIlEBzCYiZyWPUX/DKZBSydOZYOMTVg8BHZ01 X628oVbRhKJ2wWqNt28qOGmp1ysqGTJlqRKhDU5fLLzYmXXKcmCp1Q7zdE9OjCR8sBN0 L8IRkHMzSWOTLVdw+mB0iJ61JoMNgCzB+hKi1Zw02QQhbujc+3afq8WfU5SYW85XzYIt YadFuoEQ2+X6VQe3BkpTn5j+aNHFK1jpHWp6+x9GVZECrvDDXrSdoi8aWhnManEhm/Zz +tEA== X-Gm-Message-State: ALoCoQnKYYVDs/jt13e/sY+JruxDjnam1Xw/oSOBlC4skWBy6du9XQD1oBjRsU+ME7q+Uyggyc8G8vBxUBX90LKOJxS8Tt/rAw== MIME-Version: 1.0 X-Received: by 10.202.189.7 with SMTP id n7mr8783863oif.55.1450745663365; Mon, 21 Dec 2015 16:54:23 -0800 (PST) Received: by 10.76.62.8 with HTTP; Mon, 21 Dec 2015 16:54:23 -0800 (PST) In-Reply-To: References: Date: Mon, 21 Dec 2015 14:54:23 -1000 Message-ID: From: Brian Smith To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113d7032ecc07a0527720b04 Archived-At: Cc: Adam Langley , "" Subject: Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Dec 2015 00:54:25 -0000 --001a113d7032ecc07a0527720b04 Content-Type: text/plain; charset=UTF-8 Eric Rescorla wrote: > Sorry, I'm still confused TLS 1.2 uses a specific PRF. TLS 1.3 uses HKDF. > Are you suggesting TLS 1.2 use the TLS 1.2 PRF with SHA-512 and that > TLS 1.2 use SHA-512 with HKDF, or something different? > I mean that TLS 1.2 should use SHA-512 with the TLS 1.2 PRF and that TLS 1.3 should use SHA-512 with HKDF. > Nobody should pay attention to what the MTI cipher suite for TLS 1.2 is, >> because it's obsolete; in fact, one would be making a huge mistake to >> deploy it now if one's application didn't have legacy backward >> compatibility concerns. And, we should change the MTI cipher suite for TLS >> 1.3 to the ChaCha20-Poly1305 ones, because they solve a lot of problems. >> For example, they remove any question of any need to implement rekeying, >> they avoid the weird IV construction hacks that are necessary for 128-bit >> cipher suites like AES-GCM, and they can be implemented efficiently in a >> safe way, unlike AES-GCM. >> > > This seems like a separate question. > You are the one that brought the MTI stuff into this, not me. > SHA-256-using cipher suites are widely deployed and not going away any > time soon, so what resource are you trying to conserve here? > I'm trying to minimize the number of algorithms (amount of code) necessary to implement ChaCha20-Poly1305 using x25519 for key agreement and Ed25519 for signatures. The different between needing or not needing SHA-256 matters most for very small computers (AVR and Cortex-M0), but doesn't really matter much for larger computers where SHA-256 has an advantage. In particular, since there seems to be a notable amount of hardware that is or will soon be released that optimized for ChaCha20-Poly1305+x25519+Ed25519, because of Apple HomeKit, it would be nice to take advantage of that for TLS. Besides that, the inconsistency regarding why these new 256-bit-encryption-key cipher suites are currently defined to use SHA-256 in the PRF whereas all the existing 256-bit-encryption-key cipher suites use SHA-384 seems strange. Even if an application wants to use AES-GCM cipher suites, it would be able to avoid needing SHA-256 if it implemented the AES256-GCM cipher suites instead of AES128-GCM. Cheers, Brian -- https://briansmith.org/ --001a113d7032ecc07a0527720b04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Eric= Rescorla <ekr@rtfm.com> wrote:
=
Sorry, I'm still confused TLS 1.2 uses a specific PRF. TLS 1.3 use= s HKDF.
Are you suggesting TLS 1.2 use the TLS 1.2 PRF= with SHA-512 and that
TLS 1.2 use SHA-512 with HKDF, or somethin= g different?

I mean= that TLS 1.2 should use SHA-512 with the TLS 1.2 PRF and that TLS 1.3 shou= ld use SHA-512 with HKDF.
=C2=A0
Nobody should pay attention to what the MTI = cipher suite for TLS 1.2 is, because it's obsolete; in fact, one would = be making a huge mistake to deploy it now if one's application didn'= ;t have legacy backward compatibility concerns. And, we should change the M= TI cipher suite for TLS 1.3 to the ChaCha20-Poly1305 ones, because they sol= ve a lot of problems. For example, they remove any question of any need to = implement rekeying, they avoid the weird IV construction hacks that are nec= essary for 128-bit cipher suites like AES-GCM, and they can be implemented = efficiently in a safe way, unlike AES-GCM.

This seems like a separate questi= on.

You are the one that broug= ht the MTI stuff into this, not me.
=C2=A0
=
SHA-256-using cipher suites are widely deployed and not going away any tim= e soon, so what resource are you trying to conserve here?
=

I'm trying to minimize the numbe= r of algorithms (amount of code) necessary to implement ChaCha20-Poly1305 u= sing x25519 for key agreement and Ed25519 for signatures. The different bet= ween needing or not needing SHA-256 matters most for very small computers (= AVR and Cortex-M0), but doesn't really matter much for larger computers= where SHA-256 has an advantage.

In particular, si= nce there seems to be a notable amount of hardware that is or will soon be = released that optimized for ChaCha20-Poly1305+x25519+Ed25519, because of Ap= ple HomeKit, it would be nice to take advantage of that for TLS.
=
Besides that, the inconsistency regarding why these new 256-= bit-encryption-key cipher suites are currently defined to use SHA-256 in th= e PRF whereas all the existing 256-bit-encryption-key cipher suites use SHA= -384 seems strange. Even if an application wants to use AES-GCM cipher suit= es, it would be able to avoid needing SHA-256 if it implemented the AES256-= GCM cipher suites instead of AES128-GCM.

Cheers,
Brian
--
--001a113d7032ecc07a0527720b04-- From nobody Mon Dec 21 17:49:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E411AD066 for ; Mon, 21 Dec 2015 17:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_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 aXxEmkYCuNKe for ; Mon, 21 Dec 2015 17:49:34 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0145.outbound.protection.outlook.com [65.55.169.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711B01AD063 for ; Mon, 21 Dec 2015 17:49:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yfRHxyx32MtpL44xe646MEddPc84HEKyLD0aZnf6NJk=; b=HAM9Mggijdc/nr7acVFiFfCUHT2zmzXoXevgAzaeLNKPaeLpXD/DG3TJegNhTRkBPg8Fj9rdqZ808fibKS6TKcG7wC8XcUP2mANj/TaxrnNi/YlKP8kJIXy0lBiiqsHsPFG7qpZ986JjP3nWy1Yxu8Z29P8sVDis88OvevxV6S0= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 22 Dec 2015 01:49:32 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0361.006; Tue, 22 Dec 2015 01:49:32 +0000 From: Christian Huitema To: "tls@ietf.org" Thread-Topic: What does it mean to not include 0-RTT message in the handshake hash? Thread-Index: AdE8WUzTusUbdu5EQyy4pojDDNAspQ== Date: Tue, 22 Dec 2015 01:49:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [131.107.160.143] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 5:tIFDYKAPV7QmEeu05Mpv65G1VP1OOTt9TSneGFsUOMH8esmx8SeyXAPWcHAihOWMRo6DO74yCRohtvH3LePFY4OS1gsqs2JBkVxqdBvpt09cGe0ZGzzCI4bwMtOM7bw6COz8GpsV9Kzskv0fHv7//Q==; 24:lXn7eRLuLIQQVxId0Was+E2eA1dX1+cRge5nArcscL70mBVsqO/L5+b5YjGrzdDDK3XQdddpXB3e37HJ/iTSIlU0Pisf/VJuZ7daYJXUl20= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653; x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 0798146F16 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(76576001)(5004730100002)(40100003)(50986999)(86362001)(66066001)(77096005)(102836003)(3846002)(54356999)(86612001)(87936001)(5008740100001)(2900100001)(122556002)(5002640100001)(92566002)(5003600100002)(6116002)(10290500002)(10400500002)(5005710100001)(450100001)(8990500004)(2501003)(1730700002)(81156007)(110136002)(5001960100002)(229853001)(189998001)(107886002)(10090500001)(74316001)(97736004)(99286002)(586003)(33656002)(11100500001)(1220700001)(2351001)(1096002)(101416001)(106356001)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2015 01:49:32.5278 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 Archived-At: Subject: [TLS] What does it mean to not include 0-RTT message in the handshake 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, 22 Dec 2015 01:49:36 -0000 The handshake hash specification in section 7.1 says: Where handshake_hash includes all messages up through the server CertificateVerify message, but not including any 0-RTT handshake messages (the server's Finished is not included because the master_secret is need to compute the finished key). What are the 0-RTT handshake messages that should be excluded? The diagram = in 6.2.2 shows the client hello and its extensions, the optional client cer= t and client cert verify, and a finished message. Presumably, the handshake= hash does not exclude the client hello. What is the intent there? Is the s= entence meant to exclude the 0-RTT cert, cert verify and finished messages? -- Christian Huitema From nobody Mon Dec 21 18:03:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4440D1AD0AA for ; Mon, 21 Dec 2015 18:03:28 -0800 (PST) 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, HTML_MESSAGE=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 suvcbIVFxHpN for ; Mon, 21 Dec 2015 18:03:27 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19C91AD0A6 for ; Mon, 21 Dec 2015 18:03:26 -0800 (PST) Received: by mail-yk0-x229.google.com with SMTP id 140so149856785ykp.0 for ; Mon, 21 Dec 2015 18:03:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HolATKKcFxmXyBZNcLzMkWC0u26fDmBRLn4M/8C34tk=; b=OqcWMiU5NVROIxnlgqMt54gAjCGWNPo4Rf7Ekdz5XriG9lC3KWgCIExftPlaUQfFEn YHsLKkxKGCZpcHMStUpX9MHcFy6RVrgi9Fwg4462kHP0qR+vMiUioPQ2BVjd4kam8qP5 Xwp3A4i7T1wjYMhLYBvloAXFMVWhKaBW98UnQpvgKxWVoBZYwyn1xVF1E12dmvvAfcY5 Vzmb0zUQ6D4xBxNC1CZRKJ64pCZZATKMg+7fGEayXZAz78IxUz9JeNNgag0DUbIIaRg2 ijZYaDOdT0J4VdSnVFjTT/cLafFrHmWT0jh72A9WFt37KBcueNWY0bk3Q8mrBzz2xOrk i6ug== 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=HolATKKcFxmXyBZNcLzMkWC0u26fDmBRLn4M/8C34tk=; b=YFiN1hWw288F+jAm4dqJ9KNuPEJhCMBZZVwYid+aLKuVNnNwPASLaE6siPBJjj6mFz WFN0hfozU14oQKUaDqJCqqIEyVL0/2I4o5RpqlF7ZK27uyrCoqrqgDCHoKgVP8D+7u2l /W+MTvaznkUHTaZTfvabsymf8LPPIR40/a02Wjx0qY1hFreetW9bjd+tq5yLqe+op1Uj VMOF+ru3lL7wzAeKCWMyINLRxHoLrwuRRSyWKFdOwkGKbHYqk7zJWNb226XNeURyxEfR lpr/87KmlsFDH6IyFuHeNLDzrC3sjUYdZCveCosU58A7WN9qRFDu0ksEo/XjCXxpcMdy WnkQ== X-Gm-Message-State: ALoCoQm7BbdzWfUxPKwZztlkNhzGzyWM+23FQVEasNbFiCCBw08uSCO6DCZhbGtcNHXmnKf427VPuWM0HA+ixN9KrJIQ0Mcb/w== X-Received: by 10.129.46.208 with SMTP id u199mr17188578ywu.129.1450749806009; Mon, 21 Dec 2015 18:03:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Mon, 21 Dec 2015 18:02:46 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Mon, 21 Dec 2015 18:02:46 -0800 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=001a11408592d892a60527730235 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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, 22 Dec 2015 02:03:28 -0000 --001a11408592d892a60527730235 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 21, 2015 at 5:49 PM, Christian Huitema wrote: > The handshake hash specification in section 7.1 says: > You're referring the editor's copy (WIP-11), right? > Where handshake_hash includes all messages up through the > server CertificateVerify message, but not including any > 0-RTT handshake messages (the server's Finished is not > included because the master_secret is need to compute > the finished key). > > What are the 0-RTT handshake messages that should be excluded? The diagram > in 6.2.2 shows the client hello and its extensions, the optional client > cert and client cert verify, and a finished message. Presumably, the > handshake hash does not exclude the client hello. What is the intent there? > Is the sentence meant to exclude the 0-RTT cert, cert verify and finished > messages? > I was just going over this text today and realized it's kind of confusing (and the whole "handshake_hash" abstraction is starting to be less useful in light of the PR#316 reframing of the authentication block). Unless I'm confused (which is possible given the time of night), the intention, as you say, is to separate out the 0-RTT handshake messages i.e., (cert, cert verify, finished) from the 1-RTT computations. However, as indicated in S 6.3.3. and 6.3.4: - The 0-RTT Certificate Verify covers the ClientHello and Certificate (as well as the cached messages from the server shown in the table in 6.3.4) - The 0-RTT Finished includes the above messages plus the CertificateVerify. Trying to figure out the best way to clarify this text. PRs welcome :) -Ekr --001a11408592d892a60527730235 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 21, 2015 at 5:49 PM, Christian Huitema &l= t;huitema@micros= oft.com> wrote:
The handsha= ke hash specification in section 7.1 says:

<= div>You're referring the editor's copy (WIP-11), right?
<= br>
=C2=A0
=C2=A0 Where handshake_hash includes all messages up through the
=C2=A0 server CertificateVerify message, but not including any
=C2=A0 0-RTT handshake messages (the server's Finished is not
=C2=A0 included because the master_secret is need to compute
=C2=A0 the finished key).

What are the 0-RTT handshake messages that should be excluded? The diagram = in 6.2.2 shows the client hello and its extensions, the optional client cer= t and client cert verify, and a finished message. Presumably, the handshake= hash does not exclude the client hello. What is the intent there? Is the s= entence meant to exclude the 0-RTT cert, cert verify and finished messages?=

I was just going over this text today = and realized it's kind of confusing
(and the whole "hand= shake_hash" abstraction is starting to be less useful
in lig= ht of the PR#316 reframing of the authentication block).

Unless I'm confused (which is possible given the time of night),= =C2=A0
the intention, as you say, is to separate out the 0-RTT ha= ndshake
messages i.e., (cert, cert verify, finished) from the 1-R= TT computations.
However, =C2=A0as indicated in S 6.3.3. and 6.3.= 4:

- The 0-RTT Certificate Verify covers the Clien= tHello and Certificate
=C2=A0 (as well as the cached messages fro= m the server shown in the
=C2=A0 table in 6.3.4)
- The = 0-RTT Finished includes the above messages plus the
=C2=A0 Certif= icateVerify.

Trying to figure out the best way to = clarify this text. PRs welcome :)

-Ekr
<= br>




<= br>
--001a11408592d892a60527730235-- From nobody Mon Dec 21 18:26:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085321AD0C9 for ; Mon, 21 Dec 2015 18:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 1dPWRv8dNAuX for ; Mon, 21 Dec 2015 18:26:03 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D681AD0B4 for ; Mon, 21 Dec 2015 18:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8djJy0XkR/Cz2jXhOSf5pK9TZ5SOlPyb+P7u5Cc0H6Q=; b=a8baHyvssk4aMyI+xRCg9nLrr4vqtWndCwKV/kZYpwOfuNk1XYptxJxsNmW8OOXSW6eq16tERNf2KIz8SnVw9zFbhMnrBZHDuFF+c/Zj+oBF/7fNDf1scoqrknkCv02zXh2cPv6TdqY8F4se2RB9A8Xd2aM3YvbpbuF8ea/pVQg= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 22 Dec 2015 02:25:44 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0361.006; Tue, 22 Dec 2015 02:25:44 +0000 From: Christian Huitema To: Eric Rescorla Thread-Topic: [TLS] What does it mean to not include 0-RTT message in the handshake hash? Thread-Index: AdE8WUzTusUbdu5EQyy4pojDDNAspQAA40EAAACQIQA= Date: Tue, 22 Dec 2015 02:25:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [2001:4898:80e8:c::7a9] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 5:XKAEDQFP3A5V8OT5/YRT4wDsCICu2rcjM+VzJ5lz32bJxvPnGoFiu3fGTGuaNtEyuHy+KU8kZDmUKSwAOMJe1G6ZiPTEdkGWMBXQ6DeXBoxA3ZA1zG0iSZuAOJnQAMUIrDF/mJ0EWMWcbGHCOqJgfQ==; 24:JCdkA4UP4Fv22YphQV6l8o8bLHZKf0LcFfhQTyDbWFfgVI/QvXivvCsmgr1+usahMBPSPPdwmaLw95mwg1wmrqIg/JIZqkKUzFqnkp7A0BE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 0798146F16 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(5001960100002)(189998001)(10090500001)(74316001)(81156007)(110136002)(1220700001)(1096002)(11100500001)(105586002)(106356001)(101416001)(97736004)(586003)(33656002)(99286002)(102836003)(77096005)(5008740100001)(54356999)(87936001)(86612001)(5004730100002)(76576001)(76176999)(86362001)(40100003)(50986999)(10400500002)(5005710100001)(10290500002)(8990500004)(5003600100002)(5002640100001)(92566002)(2950100001)(2900100001)(122556002)(6116002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2015 02:25:44.7899 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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, 22 Dec 2015 02:26:06 -0000 PiBZb3UncmUgcmVmZXJyaW5nIHRoZSBlZGl0b3IncyBjb3B5IChXSVAtMTEpLCByaWdodD8NCg0K WWVzLg0KLi4uDQo+IEkgd2FzIGp1c3QgZ29pbmcgb3ZlciB0aGlzIHRleHQgdG9kYXkgYW5kIHJl YWxpemVkIGl0J3Mga2luZCBvZiBjb25mdXNpbmcNCj4gKGFuZCB0aGUgd2hvbGUgImhhbmRzaGFr ZV9oYXNoIiBhYnN0cmFjdGlvbiBpcyBzdGFydGluZyB0byBiZSBsZXNzIHVzZWZ1bA0KPiBpbiBs aWdodCBvZiB0aGUgUFIjMzE2IHJlZnJhbWluZyBvZiB0aGUgYXV0aGVudGljYXRpb24gYmxvY2sp Lg0KDQpZZXMsIHRoZSAiaGFuZHNoYWtlIGhhc2giIGlzIGluZGVlZCBjb25mdXNpbmcuIFNwZWNp Znlpbmcgc29tZXRoaW5nIGxpa2UgImFsbCBtZXNzYWdlcyB1cCB0byA8c29tZSBwb2ludD4iIGlz IHNpbXBsZSBlbm91Z2guIEJ1dCB0aGVyZSBhcmUgc2V2ZXJhbCBzdWNoIHBvaW50cywgdXNlZCBh dCBkaWZmZXJlbnQgc3RhZ2VzLiBTZXJ2ZXIgSGVsbG8sIFNlcnZlciBjZXJ0aWZpY2F0ZSB2ZXJp ZnksIFNlcnZlciBGaW5pc2hlZCwgQ2xpZW50IGNlcnRpZmljYXRlIHZlcmlmeSwgQ2xpZW50IGZp bmlzaGVkLi4gSXQgd291bGQgYmUgYSBiaXQgbW9yZSBjbGVhciB0byBnaXZlIGVhY2ggb2YgdGhl bSBpdHMgb3duIG5hbWUuDQoNCj4gVW5sZXNzIEknbSBjb25mdXNlZCAod2hpY2ggaXMgcG9zc2li bGUgZ2l2ZW4gdGhlIHRpbWUgb2YgbmlnaHQpLMKgDQo+IHRoZSBpbnRlbnRpb24sIGFzIHlvdSBz YXksIGlzIHRvIHNlcGFyYXRlIG91dCB0aGUgMC1SVFQgaGFuZHNoYWtlDQo+IG1lc3NhZ2VzIGku ZS4sIChjZXJ0LCBjZXJ0IHZlcmlmeSwgZmluaXNoZWQpIGZyb20gdGhlIDEtUlRUIGNvbXB1dGF0 aW9ucy4NCg0KT0suIFRoYXQgZG9lcyBub3Qgc2ltcGxpZnkgaW1wbGVtZW50YXRpb25zIHVzaW5n IHJ1bm5pbmcgaGFzaGVzLi4uDQoNCj4gVHJ5aW5nIHRvIGZpZ3VyZSBvdXQgdGhlIGJlc3Qgd2F5 IHRvIGNsYXJpZnkgdGhpcyB0ZXh0LiBQUnMgd2VsY29tZSA6KQ0KDQpZZXMgb2YgY291cnNlLi4u DQoNCi0tIENocmlzdGlhbiBIdWl0ZW1hDQoNCg0KDQoNCg0KDQo= From nobody Mon Dec 21 18:30:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71471AD0D2 for ; Mon, 21 Dec 2015 18:30:03 -0800 (PST) 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 hK-SB83OW_qE for ; Mon, 21 Dec 2015 18:30:02 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4E21AD0D0 for ; Mon, 21 Dec 2015 18:30:02 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id o67so173346897iof.3 for ; Mon, 21 Dec 2015 18:30:02 -0800 (PST) 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=HQvdtDQ7w1V8yOYIDCDgOh9jyQ5oWqczomklYovMHd0=; b=P4dmJab+x8gF7hiTmLiCz9ZgAAbbFMgKc3DDWmylkm+W6AhqoOI1Ins2yYr9t6MzZZ gQ9PzksVCqmLuxGulSo93QMsEm/YMvQbbWB5dRBY7/cgwXoRgZFlyp4lRIiW2SomZeTX SnXQu1hVqYACd7HnvCzIJaN4MDNex/k0LAcTQRIQYCRdZKM4G56CIn3zKSlRQEDzo6Sb 4XiNrFwCmKPUK0AFNj5x4HKQV2HxQfxLinc8q/R7Kn4wXiTXol1792mpliYKnop0obhF k/dEw/K6XCzx7x+MZy4voBpko6VLjoIBkBx0fTZSZRaMavKX8Y1PCSEcc5K28W8rFaRa Uzqg== MIME-Version: 1.0 X-Received: by 10.107.131.40 with SMTP id f40mr10488890iod.190.1450751401900; Mon, 21 Dec 2015 18:30:01 -0800 (PST) Received: by 10.36.149.130 with HTTP; Mon, 21 Dec 2015 18:30:01 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Dec 2015 13:30:01 +1100 Message-ID: From: Martin Thomson To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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, 22 Dec 2015 02:30:03 -0000 On 22 December 2015 at 13:25, Christian Huitema wrote: >> Unless I'm confused (which is possible given the time of night), >> the intention, as you say, is to separate out the 0-RTT handshake >> messages i.e., (cert, cert verify, finished) from the 1-RTT computations. > > OK. That does not simplify implementations using running hashes... It does if you consider the possibility of having to drop the 0-RTT data. From nobody Mon Dec 21 18:33:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346381AD0C6 for ; Mon, 21 Dec 2015 18:33:22 -0800 (PST) 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 u6-2iTT1aOHo for ; Mon, 21 Dec 2015 18:33:21 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF3091A872B for ; Mon, 21 Dec 2015 18:33:20 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id t125so144623127qkh.3 for ; Mon, 21 Dec 2015 18:33:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=DnSrxGDCLfsNrm9hmpHDUs3kCT/K95wwVa/hFKeVXW4=; b=0KC8QLzIzbCtDsLh6XZtCGhxemhfKpBztPTiRD9egwJyisWNikuWA5wHAzyb3pO7eS +hyUuuxWD69AuNtbSqA6pO2fZsm2Bg6dxf6xpiZgCL2NWcDEpNVjNcys/pEqbG+72lIZ VI1BdVGx+EKS7swEHvfYzuAXAEYaxp5CsMRUXw7rdW4pxNRezGRBPRFAKKyzjK1CGO8H CyJX29GePUbdv7aT+LoWiiBPB0TXP1fFinjXmeC+pYO+EA9D93Od53ZotKdosUAMzopS Bmjrn5WdR3PwP/yp76oiZidOAeTqG5zQlBXhMfuOovyNhjFFCBcXMUr5oAq2emk8l2Kl ej7g== X-Received: by 10.55.81.132 with SMTP id f126mr28927180qkb.88.1450751600199; Mon, 21 Dec 2015 18:33:20 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id w16sm15295117qka.35.2015.12.21.18.33.19 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 21 Dec 2015 18:33:19 -0800 (PST) From: Dave Garrett To: tls@ietf.org, Eric Rescorla Date: Mon, 21 Dec 2015 21:33:17 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201512212133.17838.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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, 22 Dec 2015 02:33:22 -0000 On Monday, December 21, 2015 09:25:44 pm Christian Huitema wrote: > > I was just going over this text today and realized it's kind of confusing > > (and the whole "handshake_hash" abstraction is starting to be less useful > > in light of the PR#316 reframing of the authentication block). > > Yes, the "handshake hash" is indeed confusing. Specifying something like "all messages up to " is simple enough. But there are several such points, used at different stages. Server Hello, Server certificate verify, Server Finished, Client certificate verify, Client finished.. It would be a bit more clear to give each of them its own name. Along this same line, I'd suggest getting rid of "session_hash", at least as-is. Instead, just use "handshake_hash" for everything and specify what's included at each use. "Session hash" is just another term that has to be referenced, when it's just the final state of the handshake hash. The term doesn't really add anything unless every separate stage of the handshake hash was named separately (in which case, "handshake_hash_*" naming might be more clear) Dave From nobody Mon Dec 21 18:41:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2325F1AD1BA for ; Mon, 21 Dec 2015 18:41:20 -0800 (PST) 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, HTML_MESSAGE=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 adofa35aYUsS for ; Mon, 21 Dec 2015 18:41:19 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F96A1AD1A6 for ; Mon, 21 Dec 2015 18:41:19 -0800 (PST) Received: by mail-yk0-x236.google.com with SMTP id 140so150544415ykp.0 for ; Mon, 21 Dec 2015 18:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HVyQ55V3sEMpHS9DyFYhs9w7pMqC1RbahR6AxIUd2bM=; b=JYdlLlGGwf3mp+XwRNKmjD4LZtwx5UpgnkUwf0vGiympFApYTZmEjKw10YOccPAii5 9YC64H4/UliuoROz7DuIHLyoletJrb9BVXrQz5i6kfcuGf/pGEzPrjGLJJHzWu2F7BbF zP7Op+KlgSjIFdefc5/wAjsBRcJ4r+vnx7vkImOZtldS9Z6SAEUsZ3WG5ozUUU6bII4Y O+vc+4UfkVe6lEa944FJkWLxqKg42oFnpWn2FXy0oFXFFUGgnj88ZGndcrYpLbw4lRLF +dQTRY3srGpjCoxC4gm9GzENT2enmkGcv55V1Y7kG1qdG6MHRwBoh4L93gO62lKX30vp aMmQ== 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=HVyQ55V3sEMpHS9DyFYhs9w7pMqC1RbahR6AxIUd2bM=; b=Bl5yqBo7CGkRkni39AtkyRc8efo12Ojysqj0T0PrcD3dH3j4cq1q7LabYWReNiRwh/ tdNoeuFcdMBUV3cgjgQnH/sVARYe7cRYR9neCl9ug+crLoSIVZ9qkchfp6F9OhxfgJ2A 5/CWpX6i5hbq+CGmK6mzV2wvhHD3V4eXkAeP2RYT7mjdqzyDpp1N/zW73439tNGfxMRl nzl65FC0YxsiAlEzUpyS6EBq4NGw5uz8px76C5hl3uye5S6yyHFzqSOp9xDw9yW4GL6E Pa466xKaI2op+jdHfOBg2kbQIofi5oRa2NwYw7/+QPb45vqFQuiYKNZy4AUJFxEbUZlB Xenw== X-Gm-Message-State: ALoCoQnGmZili30PHgK3GyxLinGP2X/cVs9FBAZf7mSBA7wtogVHi1/vTD6ePFVO/uiLLxtwJLr6ivTf6Rl3IX7+9xVz3Dok4g== X-Received: by 10.129.73.133 with SMTP id w127mr19837171ywa.223.1450752078369; Mon, 21 Dec 2015 18:41:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Mon, 21 Dec 2015 18:40:39 -0800 (PST) In-Reply-To: <201512212133.17838.davemgarrett@gmail.com> References: <201512212133.17838.davemgarrett@gmail.com> From: Eric Rescorla Date: Mon, 21 Dec 2015 18:40:39 -0800 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a114dcf6a4a047c0527738a38 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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, 22 Dec 2015 02:41:20 -0000 --001a114dcf6a4a047c0527738a38 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 21, 2015 at 6:33 PM, Dave Garrett wrote: > On Monday, December 21, 2015 09:25:44 pm Christian Huitema wrote: > > > I was just going over this text today and realized it's kind of > confusing > > > (and the whole "handshake_hash" abstraction is starting to be less > useful > > > in light of the PR#316 reframing of the authentication block). > > > > Yes, the "handshake hash" is indeed confusing. Specifying something like > "all messages up to " is simple enough. But there are several > such points, used at different stages. Server Hello, Server certificate > verify, Server Finished, Client certificate verify, Client finished.. It > would be a bit more clear to give each of them its own name. > > Along this same line, I'd suggest getting rid of "session_hash", at least > as-is. Instead, just use "handshake_hash" for everything and specify what's > included at each use. "Session hash" is just another term that has to be > referenced, when it's just the final state of the handshake hash. I tend to agree > The term doesn't really add anything unless every separate stage of the > handshake hash was named separately (in which case, "handshake_hash_*" > naming might be more clear) Yeah, that might work. I'm putting the final touches on draft-11 and will see what I can do to clarify this. Thanks -Ekr > > > Dave > --001a114dcf6a4a047c0527738a38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 21, 2015 at 6:33 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Monday, December 21, 2015 09:25:44 pm Christian Huitema wrote:
> > I was just going over this text today and realized it's kind = of confusing
> > (and the whole "handshake_hash" abstraction is starting= to be less useful
> > in light of the PR#316 reframing of the authentication block). >
> Yes, the "handshake hash" is indeed confusing. Specifying so= mething like "all messages up to <some point>" is simple en= ough. But there are several such points, used at different stages. Server H= ello, Server certificate verify, Server Finished, Client certificate verify= , Client finished.. It would be a bit more clear to give each of them its o= wn name.

Along this same line, I'd suggest getting rid of "session_h= ash", at least as-is. Instead, just use "handshake_hash" for= everything and specify what's included at each use. "Session hash= " is just another term that has to be referenced, when it's just t= he final state of the handshake hash.

I te= nd to agree

=C2=A0
The term doesn't really add anything unless every separate stage o= f the handshake hash was named separately (in which case, "handshake_h= ash_*" naming might be more clear)

Yea= h, that might work.

I'm putting the final touc= hes on draft-11 and will see what I can do to clarify this.

<= /div>
Thanks
-Ekr
=C2=A0


Dave

--001a114dcf6a4a047c0527738a38-- From nobody Tue Dec 22 04:53:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780C01A891F for ; Tue, 22 Dec 2015 04:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-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 AxREKKFcbpPa for ; Tue, 22 Dec 2015 04:53:32 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738A11A891D for ; Tue, 22 Dec 2015 04:53:32 -0800 (PST) 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 (Postfix) with ESMTPS id C1A7A42E5CE; Tue, 22 Dec 2015 12:53:30 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-113.brq.redhat.com [10.34.0.113]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBMCrREY013804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Dec 2015 07:53:30 -0500 From: Hubert Kario To: tls@ietf.org Date: Tue, 22 Dec 2015 13:53:22 +0100 Message-ID: <3293494.XPNSX3av0N@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.7-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1801479.mcPsWBGueE"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: Adam Langley Subject: Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Dec 2015 12:53:34 -0000 --nextPart1801479.mcPsWBGueE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 21 December 2015 14:54:23 Brian Smith wrote: > Eric Rescorla wrote: > > Sorry, I'm still confused TLS 1.2 uses a specific PRF. TLS 1.3 uses= > > HKDF. Are you suggesting TLS 1.2 use the TLS 1.2 PRF with SHA-512 > > and that TLS 1.2 use SHA-512 with HKDF, or something different? >=20 > I mean that TLS 1.2 should use SHA-512 with the TLS 1.2 PRF and that > TLS 1.3 should use SHA-512 with HKDF. >=20 > > Nobody should pay attention to what the MTI cipher suite for TLS 1.= 2 > > is,>=20 > >> because it's obsolete; in fact, one would be making a huge mistake= > >> to > >> deploy it now if one's application didn't have legacy backward > >> compatibility concerns. And, we should change the MTI cipher suite= > >> for TLS 1.3 to the ChaCha20-Poly1305 ones, because they solve a > >> lot of problems. For example, they remove any question of any need= > >> to implement rekeying, they avoid the weird IV construction hacks > >> that are necessary for 128-bit cipher suites like AES-GCM, and > >> they can be implemented efficiently in a safe way, unlike AES-GCM.= > >=20 > > This seems like a separate question. >=20 > You are the one that brought the MTI stuff into this, not me. >=20 > > SHA-256-using cipher suites are widely deployed and not going away > > any time soon, so what resource are you trying to conserve here? > I'm trying to minimize the number of algorithms (amount of code) > necessary to implement ChaCha20-Poly1305 using x25519 for key > agreement and Ed25519 for signatures. The different between needing > or not needing SHA-256 matters most for very small computers (AVR and= > Cortex-M0), but doesn't really matter much for larger computers where= > SHA-256 has an advantage. >=20 > In particular, since there seems to be a notable amount of hardware > that is or will soon be released that optimized for > ChaCha20-Poly1305+x25519+Ed25519, because of Apple HomeKit, it would > be nice to take advantage of that for TLS. >=20 > Besides that, the inconsistency regarding why these new > 256-bit-encryption-key cipher suites are currently defined to use > SHA-256 in the PRF whereas all the existing 256-bit-encryption-key > cipher suites use SHA-384 seems strange. Even if an application wants= > to use AES-GCM cipher suites, it would be able to avoid needing > SHA-256 if it implemented the AES256-GCM cipher suites instead of > AES128-GCM. I'm not convinced about SHA-512, but yes, they probably should use=20 SHA-384 at the very least. And given that the algorithm for SHA-384 and= =20 SHA-512 is essentially the same, using just different IVs, that should=20= be usable for highly restricted hardware, wouldn't it? I would be against SHA-512 as that would be the very first cipher that=20= uses SHA-512 PRF in TLS1.2, making its addition/implementation much mor= e=20 invasive to the underlying library, OTOH, we have multiple ciphers whic= h=20 use SHA-384 PRF. I think I just need to remind the delay after which NS= S=20 added support for SHA-384 compared to introduction to AES-128-GCM TLS=20= ciphers... =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart1801479.mcPsWBGueE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJWeUfCAAoJEJKo0bgB0vX1T7IP/0b/uYZiRUgkYcOMpd5jENRe QdlQ055Cnd+iNcmx+SBPjHxaeKh/S4+pw7u0HWB0ecohLuAQdXtOOt4lo6iJNssN 289pvQEKUS1EnhGXZv/Mdr4emLkXkoMN92SLC/OX6zrhWTV0hxFbgqevTC13dAb2 ejjXld4VMjjvgar36q6ZaoGjh2F7rGvruMGZWAhNnrkYk3ClpYJQczCD3ucdQAxg 2klJEAhjAfYgb0mO0thRAu42QiHOGMK1bgeAqbgQpW7fI5ZckoejuA141WQSzVq5 qNZ8xxG3RZPPn+BHIH4p4RYHzFl/bXbV2m5f5Xe87e2gDph/vsxTQidWUirW1p5Z rYGVvbTETPgEpts0h1BrjsRPTT1PgwiW4DZ/z15ROwlRC6aIfXUhBrNX0RJQpnFe aCA0YeLx+9bXaHfeu8/dLcn/+q6VT2bYsDnktScdNLyLCnOxMd4aKBLkghMfSw7I SmOtjgLhF7dcxttL5XioHkYv6C1swwTKSLTs3fKwOHo//MMGfU2vahwDxBK/uY3A V7tHu7G041kzOj9rW863k5avESYky7gpiA+QRBrnnq2kit2c3+0Y9PPgj9+sblfw mXOKmgl5wDJD6cDmsR86lhTe71F9mOMrAx6X8R9+uO2/vprzuGaQvsfULBzNf0WQ TdOu2uySfd7G20+mWqKb =ogoP -----END PGP SIGNATURE----- --nextPart1801479.mcPsWBGueE-- From nobody Tue Dec 22 10:52:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607791A8740 for ; Tue, 22 Dec 2015 10:52:31 -0800 (PST) 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 fNN-CzWdBrok for ; Tue, 22 Dec 2015 10:52:30 -0800 (PST) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D5FF1A8A82 for ; Tue, 22 Dec 2015 10:52:29 -0800 (PST) Received: by mail-qg0-x235.google.com with SMTP id c96so117226490qgd.3 for ; Tue, 22 Dec 2015 10:52:29 -0800 (PST) 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:cc:content-type; bh=y94EdjLECSEmZK6/eBiZXDlz9oth5hoNip3S80m2nek=; b=BSNJwZ0Indlc+FtnivUV4/W/SUQwdLE8Y2p/heesNlXb6yQnorGMgqwRIhgqFmsQqW sEyohaiiK+15wOB0ryuYeN/atRXyuCXKDiV/V52apzot5tcTtk5btx24B48WSq79J9s+ /uPOV53vA7PGYMO0oeY5irNOj+rpnFXvlLOB8n4We6fA/Vp8JQjyMJmvOvywp9HqZhDJ +rVLKBBHMXhTcDqOmTXe3geqbYEfBDJ0DVcOLDkzBQmiMuCW7IiVebYr5IlUO+lZgCsf ZEbjqyKtTxABq97Isp315KlOp8+egfNI1Xleup2lnc6NTcmygeDXqEGCGxdS+Rdhxq2h 9h+w== MIME-Version: 1.0 X-Received: by 10.140.227.199 with SMTP id x190mr36798072qhb.46.1450810348477; Tue, 22 Dec 2015 10:52:28 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.93.12 with HTTP; Tue, 22 Dec 2015 10:52:28 -0800 (PST) Date: Tue, 22 Dec 2015 10:52:28 -0800 X-Google-Sender-Auth: bu4Kc-JrOrh3plCHfFDHveeDqGY Message-ID: From: Adam Langley To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Simon Josefsson Subject: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Dec 2015 18:52:31 -0000 Curve25519, as the name suggests, operates on 255-bit numbers. When encoded as bytes, there's obviously a 256th bit that needs to be specified. Curve25519 implementations didn't set the bit but did used to vary on how they parsed it. Some would take a 256-bit number and reduce it while others would ignore the bit completely. However, I believe that implementations have converged on ignoring it. That behaviour is specified in draft-irtf-cfrg-curves and tested via the test vectors. Currently https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3 says that implementations SHOULD reject inputs with the high-bit set. I think that should be dropped. The X25519 function is specified in terms of bytes in draft-irtf-cfrg-curves and I think the TLS spec should just use that draft. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Tue Dec 22 13:14:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E6E1A904D for ; Tue, 22 Dec 2015 13:14:49 -0800 (PST) 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, 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 0j4ZsODqLuR0 for ; Tue, 22 Dec 2015 13:14:48 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D8331A904C for ; Tue, 22 Dec 2015 13:14:48 -0800 (PST) Received: by mail-ob0-x236.google.com with SMTP id iw8so152530449obc.1 for ; Tue, 22 Dec 2015 13:14:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=MLdeWzoAz9yCpPg8w/eOXWGUqw0GFxYORwrkD+D+pd4=; b=aOVprlanYQdik7HytmYkEh7IW7FeupDoEe72zRTZ7AKEBnNRzSdixUvEQCUKzVeYpw g+LZpMe/xKI4f5IFA9j5aSjk7apHjFlXKRjcFzWi8AphX2xnwk63RIDqxfpXMzzm8Hn4 zshj41JKOs1nsIjRhOlDgZLsJx6gHCyBC1ZPaWDh269uE3VEO7Sak1YcqLJknd5Zi0vf D3qL711DYACX5Mr+IA8I4eseY4DuA7MFJwiVSMf/I7KFQ9kXuZD46jm+rUqtseQNJNzZ dIrYRMglEEgz3h7hwWvh8+/sb4t7hCiVDcMTLlvLo7FyoptNdY8wUcruhZ1RwLphvvM9 cPYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=MLdeWzoAz9yCpPg8w/eOXWGUqw0GFxYORwrkD+D+pd4=; b=DlxAsLcvtzedLwcOHV9KBB8edgRU5XIl1+bTpeKS8F166MmPKtFl5vpL8lDYkitgGX oyoGUdrNuuT1MU+V52Wu4KgDuB/FhL9lysuJqbbFmetrKeE2Y9R1CWvtTAUOt4gmNZzY SR1qmS9sHqnIazSXkNSarnFBwQM76j+z+WOOV5qUoKzkj7TsbX5puKkJCN5GXJeNkaMe cXcH59cT7qL/r+I8Ytbr/0DpQPygZHK7mXYmvzGdleqxe13mIbp2WdzRS93NDQqaFqAw 1UZ2ceIypiD/Z3qns+NW6/BrpJUL9esSTsntQPMKZV1QoToogWUw5NaQo4RQhnqg11V/ OWCA== X-Gm-Message-State: ALoCoQkKcChP1NeGDTS7SQ9wDSkh7mKft26fKVNMDS7pRHbKByYjjd+XzTIRI0omxjUipp0npzeIHTecXNauwEj5EcBvL+J9Rw== MIME-Version: 1.0 X-Received: by 10.182.214.40 with SMTP id nx8mr12784159obc.20.1450818887507; Tue, 22 Dec 2015 13:14:47 -0800 (PST) Received: by 10.76.62.8 with HTTP; Tue, 22 Dec 2015 13:14:47 -0800 (PST) Date: Tue, 22 Dec 2015 11:14:47 -1000 Message-ID: From: Brian Smith To: "" Content-Type: multipart/alternative; boundary=e89a8ff1c01e6c7afa0527831807 Archived-At: Subject: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Dec 2015 21:14:49 -0000 --e89a8ff1c01e6c7afa0527831807 Content-Type: text/plain; charset=UTF-8 The current draft [1] says: Other than this recommended check, implementations do not need to ensure that the public keys they receive are legitimate: this is not necessary for security with Curve25519. However, Thai Duong (of BEAST fame, among other things) wrote that TLS 1.2 and below do seem to benefit from public key validation in "Why not validate Curve25519 public keys could be harmful" [2]. Watson Ladd had also pointed out many times on this list that TLS is one protocol where contributory behavior is required. DJB himself had also pointed out did point out that some protocols do require public key validation with Curve25519 "to ensure 'contributory' behavior" in [3]. Thus, the statement in draft-ietf-tls-curve25519-01 that "this is not necessary for security with Curve25519" in the current draft is clearly overly general and misleading. In particular, I noticed that the text in draft-ietf-tls-curve25519-01 section 2.3 focuses a lot on attacks that reveal the private key. However, what about other attacks? In particular, I think that, at the very least, the relevance or irrelevance to TLS of the key dictation attack that Thai brought up, and the need or non-need for checking that the agreed value is zero (basically the same thing), should be mentioned in the draft's security considerations. [1] https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3 [2] http://vnhacker.blogspot.com/2015/09/why-not-validating-curve25519-public.html [3] http://cr.yp.to/ecdh.html#validate Cheers, Brian -- https://briansmith.org/ --e89a8ff1c01e6c7afa0527831807 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The current draft [1] says:

=C2=A0 =C2=A0 Other tha= n this recommended check, implementations do
=C2=A0 =C2=A0 not need to e= nsure that the public keys they receive
=C2=A0 =C2=A0 are legitimate: th= is is not necessary for security
=C2=A0 =C2=A0 with Curve25519.

H= owever, Thai Duong (of BEAST fame, among other things) wrote that TLS 1.2 a= nd below do seem to benefit from public key validation in "Why not val= idate Curve25519 public keys could be harmful" [2].=C2=A0Watson Ladd h= ad also pointed out many times on this list that TLS is one protocol where = contributory behavior is required.

DJB himself had also pointed= out did point out that some protocols do require public key validation wit= h Curve25519 "to ensure 'contributory' behavior" in [3]. = Thus, the statement in draft-ietf-tls-curve25519-01 that "this is not = necessary for security with Curve25519" in the current draft is clearl= y overly general and misleading.

In particular, I = noticed that the text in draft-ietf-tls-curve25519-01 section 2.3 focuses a= lot on attacks that reveal the private key. However, what about other atta= cks? In particular, I think that, at the very least, the relevance or irrel= evance to TLS of the key dictation attack that Thai brought up, and the nee= d or non-need for checking that the agreed value is zero (basically the sam= e thing), should be mentioned in the draft's security considerations.

--e89a8ff1c01e6c7afa0527831807-- From nobody Tue Dec 22 13:36:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403521A907D for ; Tue, 22 Dec 2015 13:36:36 -0800 (PST) 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, 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 lamkTbHvNtRD for ; Tue, 22 Dec 2015 13:36:34 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92581A907C for ; Tue, 22 Dec 2015 13:36:34 -0800 (PST) Received: by mail-ob0-x231.google.com with SMTP id ba1so61586945obb.3 for ; Tue, 22 Dec 2015 13:36:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gdTydPPAKlTEAn0ybt/hJ6/Jt3ENwYSqFM66rSVQZOY=; b=hpnZqdKL0h8kHuGE1GHhy7lu876jnWIzxDNJ4mGwzBnvTuwJREjtZ4/ecAtFKlinfv ZPdbQqjiXMDW6s7pqiiTGwcRuNDgDG0O8tba19Joxv9b2lqeOlBXQHhr/QCxaWj8dus8 xcrmjq2xtStEQDSJ84d1pEPoeCNKS1F0kUDPWr6c1tmtgLAmkqhk35V2zc/Dzvu4+CvC xGLi2Bcfvs0bQfBCxJ28V9jVrtS+upjkEAmVKd3FoNzE/XsX3T2MPkEN5S1diAZ8YaZA eMqz1DnC8tmq6Dozfg9c0VUpUX76WeBzlUZkwkeDRY5RK82rtg5joBSZhtd33SbM6lLE xoXw== 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=gdTydPPAKlTEAn0ybt/hJ6/Jt3ENwYSqFM66rSVQZOY=; b=j1GtSQPX7qRbKXTFYkbdmkUOhOh+H/t7EhQA/RHqKD2Bm/W/G2XzdbK/eRUOQlH3mR T6rGHvrK8gHFE8syP98LNSNLY0jM7rfH1h/jfNra26cV3GNyFmfoF8LBVVA0GckvsC/I pEXVka66Wm8QLChr+sNpTaUwT3dj4TfXx9/lHrGipvHAafs0ic4Mn+QBzS/wtChagsu6 z5oLFM+aKhPdyf+OFaO0ziNG6j0eKo12WjD+DMYezTAUHoJf02fh6TTOCEWSFXwlpBNp Ukap1P3BTDVpuytVuTkVrbhicnMKjabhHqS00uwLB3H2S7McjE8FXYqNXR0RYeEnAGeE JdtQ== X-Gm-Message-State: ALoCoQlH8iuW1QKFe+xZkgK2H0GJVKW4QWhi1l7ImIju2UkVtlO1JevrmL/5vlMoPjsLVgE7wo9aC/F3KWNwjfCyiXmfTu9taA== MIME-Version: 1.0 X-Received: by 10.60.98.33 with SMTP id ef1mr12699922oeb.62.1450820192994; Tue, 22 Dec 2015 13:36:32 -0800 (PST) Received: by 10.76.62.8 with HTTP; Tue, 22 Dec 2015 13:36:32 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Dec 2015 11:36:32 -1000 Message-ID: From: Brian Smith To: Adam Langley Content-Type: multipart/alternative; boundary=089e0115edca3c9caf0527836642 Archived-At: Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Dec 2015 21:36:36 -0000 --089e0115edca3c9caf0527836642 Content-Type: text/plain; charset=UTF-8 Adam Langley wrote: > Currently > https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3 > says that implementations SHOULD reject inputs with the high-bit set. > I think that should be dropped. The X25519 function is specified in > terms of bytes in draft-irtf-cfrg-curves and I think the TLS spec > should just use that draft. First, maybe I'm overlooking something obvious, but I'm not seeing it: Why are we concerned only with whether the high bit has been set, instead of whether the public value has been reduced mod q (q == 2^255-19)? Aren't there ~19 interesting values that don't have the high bit set but which are also relevant to this issue? The draft notes that if the sender calculated the result correctly, then the result will never have the high bit set. So, then, we should have a requirement on the sender that the sender MUST NOT send a representation of its public value that has the high bit set? And, more generally, the sender MUST NOT send a representation of its public value that isn't reduced mod q. Would this be problematic to add this requirement? If we added the above requirement on senders, then it would matter less whether receivers reject values that aren't reduced mod q, as a conforming implementation would never send them, right? It seems like a good idea to reject non-reduced public values because: 1. By the argument in section 2.3, a conforming sender would never send them, so if the sender did send one, it means there's a problem with the sender of unknown severity, or an unknown attack on the wire. Either way, it's safest to bail out early. 2. Rejecting non-reduced values allows us to compare keys (after validation) by bytewise comparison and/or comparison of secure hashes of the bytes. AFAICT, this seems to matter less for x25519 and ECDH in general than it matters for signatures, but I bet that is just because I'm not creative enough to discover why it might matter for ECDH. I did give an example of why it can matter for signature public keys in [1]. It seems better to me to be cautious on the topic. [1] https://code.google.com/p/chromium/issues/detail?id=522228#c9 Cheers, Brian -- https://briansmith.org/ --089e0115edca3c9caf0527836642 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adam= Langley <agl@imperialviolet.org> wrote:
Currently https://tools.ie= tf.org/html/draft-ietf-tls-curve25519-01#section-2.3
says that implementations SHOULD reject inputs with the high-bit set.
I think that should be dropped. The X25519 function is specified in
terms of bytes in draft-irtf-cfrg-curves and I think the TLS spec
should just use that draft.

First, maybe I&= #39;m overlooking something obvious, but I'm not seeing it: Why are we = concerned only with whether the high bit has been set, instead of whether t= he public value has been reduced mod q (q =3D=3D 2^255-19)? Aren't ther= e ~19 interesting values that don't have the high bit set but which are= also relevant to this issue?

The draft notes that= if the sender calculated the result correctly, then the result will never = have the high bit set. So, then, we should have a requirement on the sender= that the sender MUST NOT send a representation of its public value that ha= s the high bit set? And, more generally, the sender MUST NOT send a represe= ntation of its public value that isn't reduced mod q. Would this be pro= blematic to add this requirement?

If we added the = above requirement on senders, then it would matter less whether receivers r= eject values that aren't reduced mod q, as a conforming implementation = would never send them, right?

It seems like a = good idea to reject non-reduced public values because:

=
1. By the argument in section 2.3, a conforming sender would never sen= d them, so if the sender did send one, it means there's a problem with = the sender of unknown severity, or an unknown attack on the wire. Either wa= y, it's safest to bail out early.

2. Rejecting= non-reduced values allows us to compare keys (after validation) by bytewis= e comparison and/or comparison of secure hashes of the bytes. AFAICT, this = seems to matter less for x25519 and ECDH in general than it matters for sig= natures, but I bet that is just because I'm not creative enough to disc= over why it might matter for ECDH. I did give an example of why it can matt= er for signature public keys in [1]. It seems better to me to be cautious o= n the topic.


Cheers,
Brian
--
--089e0115edca3c9caf0527836642-- From nobody Tue Dec 22 13:51:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B2C1A90CA for ; Tue, 22 Dec 2015 13:51:43 -0800 (PST) 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 bKsqxqzsDKAe for ; Tue, 22 Dec 2015 13:51:42 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEEAC1A90BF for ; Tue, 22 Dec 2015 13:51:41 -0800 (PST) Received: by mail-yk0-x236.google.com with SMTP id 140so177467543ykp.0 for ; Tue, 22 Dec 2015 13:51:41 -0800 (PST) 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=1hB/c98pFwYFFeKc3kAGXtoqfflVHfPVdH/UUxJsrzA=; b=EcQaRX6ggsicGuGDpXJNJ3RNCIFPx8Cq53LWjTAKGaavpdTw2Ldx5Z5aKiWS+1gWLC M7Sn5/5eFcjOiRk5zN9+v4CqTgW0MqGQBVGi5iWCv6qhUcrx4MRPEYoji5jxcw/2UqFj BwQlDW+O9MDAbhWZp7MzCIo+Y0bl3C0XpdWzA7bQzydD6xeZLhF89pJ8kv9Ybt6tofFw LYFh9HVGQD3rW39WEpyPWw6kUQR2+8J4tbw4e5me9oPx+1xhm2g2OHOFKgjpvlV29OWU qqFI/GVbsLUQVYsB+mXJTFyL8P6WuH/EkCYqiaN11GXrfSy7yiIBh84VBEkQ8cJWhMfR TCEA== MIME-Version: 1.0 X-Received: by 10.13.226.137 with SMTP id l131mr24005431ywe.239.1450821101117; Tue, 22 Dec 2015 13:51:41 -0800 (PST) Received: by 10.129.148.131 with HTTP; Tue, 22 Dec 2015 13:51:40 -0800 (PST) Received: by 10.129.148.131 with HTTP; Tue, 22 Dec 2015 13:51:40 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Dec 2015 16:51:40 -0500 Message-ID: From: Watson Ladd To: Brian Smith Content-Type: multipart/alternative; boundary=001a114fe2525d67b90527839c8b Archived-At: Cc: "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Dec 2015 21:51:44 -0000 --001a114fe2525d67b90527839c8b Content-Type: text/plain; charset=UTF-8 On Dec 22, 2015 4:15 PM, "Brian Smith" wrote: > > The current draft [1] says: > > Other than this recommended check, implementations do > not need to ensure that the public keys they receive > are legitimate: this is not necessary for security > with Curve25519. > > However, Thai Duong (of BEAST fame, among other things) wrote that TLS 1.2 and below do seem to benefit from public key validation in "Why not validate Curve25519 public keys could be harmful" [2]. Watson Ladd had also pointed out many times on this list that TLS is one protocol where contributory behavior is required. > > DJB himself had also pointed out did point out that some protocols do require public key validation with Curve25519 "to ensure 'contributory' behavior" in [3]. Thus, the statement in draft-ietf-tls-curve25519-01 that "this is not necessary for security with Curve25519" in the current draft is clearly overly general and misleading. > > In particular, I noticed that the text in draft-ietf-tls-curve25519-01 section 2.3 focuses a lot on attacks that reveal the private key. However, what about other attacks? In particular, I think that, at the very least, the relevance or irrelevance to TLS of the key dictation attack that Thai brought up, and the need or non-need for checking that the agreed value is zero (basically the same thing), should be mentioned in the draft's security considerations. Textbook DH does not ensure contributory behavior. Applications don't implement the required checks for poorly designed protocols. If we insert checks, applications which fail to make those checks will be vulnerable, while fixing protocols closes the hole. > > [1] https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3 > [2] http://vnhacker.blogspot.com/2015/09/why-not-validating-curve25519-public.html > [3] http://cr.yp.to/ecdh.html#validate > > Cheers, > Brian > -- > https://briansmith.org/ > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114fe2525d67b90527839c8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Dec 22, 2015 4:15 PM, "Brian Smith" <brian@briansmith.org> wrote:
>
> The current draft [1] says:
>
> =C2=A0 =C2=A0 Other than this recommended check, implementations do > =C2=A0 =C2=A0 not need to ensure that the public keys they receive
> =C2=A0 =C2=A0 are legitimate: this is not necessary for security
> =C2=A0 =C2=A0 with Curve25519.
>
> However, Thai Duong (of BEAST fame, among other things) wrote that TLS= 1.2 and below do seem to benefit from public key validation in "Why n= ot validate Curve25519 public keys could be harmful" [2].=C2=A0Watson = Ladd had also pointed out many times on this list that TLS is one protocol = where contributory behavior is required.
>
> DJB himself had also pointed out did point out that some protocols do = require public key validation with Curve25519 "to ensure 'contribu= tory' behavior" in [3]. Thus, the statement in draft-ietf-tls-curv= e25519-01 that "this is not necessary for security with Curve25519&quo= t; in the current draft is clearly overly general and misleading.
>
> In particular, I noticed that the text in draft-ietf-tls-curve25519-01= section 2.3 focuses a lot on attacks that reveal the private key. However,= what about other attacks? In particular, I think that, at the very least, = the relevance or irrelevance to TLS of the key dictation attack that Thai b= rought up, and the need or non-need for checking that the agreed value is z= ero (basically the same thing), should be mentioned in the draft's secu= rity considerations.

Textbook DH does not ensure contributory behavior. Applicati= ons don't implement the required checks for poorly designed protocols. = If we insert checks, applications which fail to make those checks will be v= ulnerable, while fixing protocols closes the hole.
>
> [1]=C2=A0https://tools.ietf.org/html/draft-ietf-tls-curve25519-0= 1#section-2.3
> [2]=C2=A0http://vnhacker.blogspot.com/2015/09/why-not-= validating-curve25519-public.html
> [3]=C2=A0http://cr.yp.t= o/ecdh.html#validate
>
> Cheers,
> Brian
> --
> https://briansmith.org/
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls
>

--001a114fe2525d67b90527839c8b-- From nobody Tue Dec 22 13:59:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFDA1A90D5 for ; Tue, 22 Dec 2015 13:59:03 -0800 (PST) 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 Z36L3HSXT-uT for ; Tue, 22 Dec 2015 13:59:02 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6DEE1A90D3 for ; Tue, 22 Dec 2015 13:59:01 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id n135so34419937qka.2 for ; Tue, 22 Dec 2015 13:59:01 -0800 (PST) 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=RC63svDI8QGySPaMtkW/96xCWZlAjEqO1o1t1BywPZA=; b=S5vo5FOEbwm8k/7MSoL5NiNGRHwfbPl2V43jNL2DsWFAdcyZdlnEqOe2KYKBMgjY3S fd6YQqf7jnlNPe1ZxBjhYrseHP2SB1Rbu0TM4U8Xlz61sc6qhM0qsPe7u2pvUc45pwwD mGWmz6xiGH/nZHjhkxdStOirFt8ngphPzlshqx8tkmVZSpInJgh7dg0gXVHDfQnmTVd4 d5tYvc4Llb0nOCSNGPWu/805kodM3BYMmPzUiRnfkSGord3NwDI+8/5ZMq+6VXEKWPmf yMpFAN+c9C1GsvKlFE21c/LBCu6slb0dkE0P8QeE1u/JKZMtu8SiWljQrx2oJiQsob1q Sbtw== MIME-Version: 1.0 X-Received: by 10.55.74.200 with SMTP id x191mr35741861qka.28.1450821540974; Tue, 22 Dec 2015 13:59:00 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.93.12 with HTTP; Tue, 22 Dec 2015 13:59:00 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Dec 2015 13:59:00 -0800 X-Google-Sender-Auth: rWHVRFP7Kht_2x9G4r0X68G8vL4 Message-ID: From: Adam Langley To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Dec 2015 21:59:03 -0000 On Tue, Dec 22, 2015 at 1:36 PM, Brian Smith wrote: > First, maybe I'm overlooking something obvious, but I'm not seeing it: Why > are we concerned only with whether the high bit has been set, instead of > whether the public value has been reduced mod q (q == 2^255-19)? Aren't > there ~19 interesting values that don't have the high bit set but which are > also relevant to this issue? You're correct, but I'm trying to say that the CFRG document defines a function that operates on bytestrings so that higher-level protocols don't have to worry about things like this. I think TLS should handle the byte strings opaquely so that we have uniform behaviour for X25519/X448 and only a single place where it needs to be tested. The behaviour of X25519/X448 for non-reduced values is also specified in the CFRG document. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Tue Dec 22 15:15:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DE81A92EC for ; Tue, 22 Dec 2015 15:15:40 -0800 (PST) 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, 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 2Go7iYEf4h0y for ; Tue, 22 Dec 2015 15:15:39 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD631A92EA for ; Tue, 22 Dec 2015 15:15:38 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id o62so110748407oif.3 for ; Tue, 22 Dec 2015 15:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p8xWtfFNNxXptAxJ1Et9lWWdBaTMPMERmyQh6lKag+I=; b=DTmww8EzelTPW8PRQkK5d0nBL+8PVF4cn1lx3kDbwJ10jLHL/+OZbkrACDMcSMZXGU TecTR2CAOO58fU28iKYG586AVzE7xEpZWcrAC0WpQ9NHMlYdHtVv3Gq9c70OWODZa3LH uS0CN1PLDuiu7elRXu0yOE6/x2bbwQC5Rs9DRoiXmTEzHqf97ISXRKeYvuhimlOC4l17 aUUrxkPBlv6nfHgu70w+c2/Y4D0UURAIINmkyOfSOpECNwAbB7Wt49NNzPC81aYYuTHj EfWm78r/emukhnqEIh6oFlJAUj7ZVLSmFwgfg82/hJqpimtvzO5+BgHrGwI+O4CrPM3f mU+g== 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=p8xWtfFNNxXptAxJ1Et9lWWdBaTMPMERmyQh6lKag+I=; b=LatvZfDESVT7VpyP5MzraYZYmK3TKw6wLflQ80xPhrcRxLUJkcEyBRZJG7BWYfztzG LQQtM3FNFoucU8VMwh/l9OTa1a8xqvLV6x07wUj/2BPUjkNBoOT3M6IHmdM7YbKnY+LU wBPF+Apglkk/i4giSaaT75lQlWxlSQ9Yv2TX2cdReIhhPCc1V3U0JFgKq56yZ4gPcHOT DZt+0XaLZXwmIWnDAGUUzPpV+spSQschAJIgl7W3kPaEFzNTT7yQ4Ftt4piumL797BXO /wN7Cc4twyQlnPCqQjDUdiODsI5/t40xnYsKwBwXUrwpM675xKHIEueYLUaAlBK4EtKb xC1Q== X-Gm-Message-State: ALoCoQlkByclkXAdt3tGNax/Di7pP57/7ryNWOYSbIJiDFRWNG3TUCyw1LIVYLSE/8NTuwdEwo0WtD/rAHxIWBpL6dClWu211Q== MIME-Version: 1.0 X-Received: by 10.202.189.7 with SMTP id n7mr12079371oif.55.1450826138216; Tue, 22 Dec 2015 15:15:38 -0800 (PST) Received: by 10.76.62.8 with HTTP; Tue, 22 Dec 2015 15:15:38 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Dec 2015 13:15:38 -1000 Message-ID: From: Brian Smith To: Adam Langley Content-Type: multipart/alternative; boundary=001a113d70329989ce052784c8ef Archived-At: Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Dec 2015 23:15:40 -0000 --001a113d70329989ce052784c8ef Content-Type: text/plain; charset=UTF-8 On Tue, Dec 22, 2015 at 11:59 AM, Adam Langley wrote: > You're correct, but I'm trying to say that the CFRG document defines a > function that operates on bytestrings so that higher-level protocols > don't have to worry about things like this. I think TLS should handle > the byte strings opaquely so that we have uniform behaviour for > X25519/X448 and only a single place where it needs to be tested. The > behaviour of X25519/X448 for non-reduced values is also specified in > the CFRG document. > I agree with all of that in principle. In fact, I think that most of section 2.3 should be removed in deference to the CFRG document, and only TLS-specific concerns should be given. I still think there is value in requiring senders to send their public value in the "normalized" form and for allowing (if not requiring) receivers to reject, at least, public values >= q, for the reasons I gave in my previous email. Ideally that would happen in the CFRG document. But, what is the status of the CFRG document? I've heard that it's past the point where changes will be accepted. Cheers, Brian -- https://briansmith.org/ --001a113d70329989ce052784c8ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 22, 2015 at 11:59 AM, Adam Langley <agl@imperialviolet.org> wrote:
You're correct, but I'm try= ing to say that the CFRG document defines a
function that operates on bytestrings so that higher-level protocols
don't have to worry about things like this. I think TLS should handle the byte strings opaquely so that we have uniform behaviour for
X25519/X448 and only a single place where it needs to be tested. The
behaviour of X25519/X448 for non-reduced values is also specified in
the CFRG document.

I agree with all of = that in principle. In fact, I think that most of=C2=A0section 2.3 should be= removed in deference to the CFRG document, and only TLS-specific concerns = should be given.

I still think there is value in r= equiring senders to send their public value in the "normalized" f= orm and for allowing (if not requiring) receivers to reject, at least, publ= ic values >=3D q, for the reasons I gave in my previous email. Ideally t= hat would happen in the CFRG document. But, what is the status of the CFRG = document? I've heard that it's past the point where changes will be= accepted.

Cheers,
Brian
-= -
--001a113d70329989ce052784c8ef-- From nobody Tue Dec 22 15:16:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412DB1A92ED for ; Tue, 22 Dec 2015 15:16:49 -0800 (PST) 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 b2NIB2I-LNI6 for ; Tue, 22 Dec 2015 15:16:48 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1564F1A92BA for ; Tue, 22 Dec 2015 15:16:48 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id jw2so68117442igc.1 for ; Tue, 22 Dec 2015 15:16:48 -0800 (PST) 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=53LcV2JUnM/LXL7dPWm0CY2Q1lP3U8q+dCwGG4i/F6I=; b=ChgKIrLymlcMUs+WcfMYZCq/EYK8EyClkzrlx/QNmE60ObUhVfcyxdaEWCmZ4ufpqk G1Q/Sy4INZvSkwA/V+YjFnQoGy67h9jkh0jr1qs9hbHcLN/50ynzLqfs0DP+rNm+rBJi GYDUalShnTcwe/xYJBgg90pyoyeapCNaWRo0J1d7wOiV8Hd7HPwmovU4pgVzIH/dUeM5 aZC5NHTOXqvDucJC3JoDjJh0LDvtCsb0cbHksxY1RkQMZ3lxbKinkFMxDUmq7OtLOxq9 U+J3o3Kqc+PGqbxodYogjZLSQ/hQXbQ1P+rSzdtB1FrspMPzZhl8G9TfqSLpuPPVZ5Zj YruA== MIME-Version: 1.0 X-Received: by 10.50.143.10 with SMTP id sa10mr6200049igb.77.1450826207501; Tue, 22 Dec 2015 15:16:47 -0800 (PST) Received: by 10.36.149.130 with HTTP; Tue, 22 Dec 2015 15:16:47 -0800 (PST) In-Reply-To: References: Date: Wed, 23 Dec 2015 10:16:47 +1100 Message-ID: From: Martin Thomson To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Dec 2015 23:16:49 -0000 On 23 December 2015 at 08:51, Watson Ladd wrote: > Textbook DH does not ensure contributory behavior. Applications don't > implement the required checks for poorly designed protocols. If we insert > checks, applications which fail to make those checks will be vulnerable, > while fixing protocols closes the hole. I've done a fair bit of reading into this issue as well, finding Thai's blog posting and a few other things. As Watson says, the protocol can be designed so that it doesn't depend on the DH exchange providing contributory behaviour. We should definitely do that either way. I understand that the checks are considered onerous by some, but I still don't understand why anyone might refuse to do them. Checking that you don't get a bad output from the DH computation is a tiny piece of code that takes almost no time at all, even if you have to worry about doing it in constant time. From nobody Tue Dec 22 15:23:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAC71ABD36 for ; Tue, 22 Dec 2015 15:23:57 -0800 (PST) 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, 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 HNp3YePWmdtl for ; Tue, 22 Dec 2015 15:23:55 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26CDF1A9308 for ; Tue, 22 Dec 2015 15:23:54 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id y66so115921246oig.0 for ; Tue, 22 Dec 2015 15:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KLs6Vx/68kyTqlEPn+536W3R7Q/fEuJyY3ZweKcAiNg=; b=uTbKm0HEz7+BaUPE4cJEdTfmKURPFP+B+V67Qx40sxfvSHtZv3BRlqXj8pezadLvpr 8j3hjUsKO9cBQAyDsssOL8ngwAkQq+8S8ch1YtqdGid+XjxR3OVcVdNg619U5xTad6rR I24ehYsfOcKs1uOWewrF+Rdu565YEnpPdnZB4dVSjklEK0nuEAbKGIrsCARYAN/csb2j Wxsa6HXdjjQKq/8UgJFwv/y8qj+WJDoL7ZfbuWX2KoR4bemfGME+avK8TlXM3crlCRQT mockI8csI6q6mgZUwHQe+WjVNlXKY8SzOy3zo34q/IFDvcMZ7/1R7/V8TSB7nJY5YnfM fLlg== 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=KLs6Vx/68kyTqlEPn+536W3R7Q/fEuJyY3ZweKcAiNg=; b=dGRQMjNIlzDx5N0hGaL2cN73Fpm7O4NiqyKx1CgaDaqMXsxxC7f8BGhGLo0lbXsu10 eUNBEG08NehbVytb+TTl5r0NoGKDwjiLowVZTD/I+MC4EO4EUuxVsf4rksTYbTCkilAe CNk6Cw/BRE0MuwAoMEI+eSkXLjZ2A3GNZ1RQSDq6Rjr2tZfhVzl4KiPMggBcy9EkmUJo 7/jIU+GVl12vX2wyLcWgIqU+L0GOC/bIpSQ+mtPmGFDxNeBJwUom75fcMYJgqlergzuL rO3fxFGnrsURzcmFpsZcPK4NAJSyEuz/JZRxEI4dpYJYAxosR05ENSgeV5Zpx7chBK22 6jPQ== X-Gm-Message-State: ALoCoQnOxuNoEmuDChwCkcpYzRZuichtI5r9bYC9Ssj6FItsb48o6C6Xg56M8uKoeQfNmnlM6jwp+MTX4fryvM9mSecI0XY8Og== MIME-Version: 1.0 X-Received: by 10.202.186.198 with SMTP id k189mr11917244oif.105.1450826633524; Tue, 22 Dec 2015 15:23:53 -0800 (PST) Received: by 10.76.62.8 with HTTP; Tue, 22 Dec 2015 15:23:53 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Dec 2015 13:23:53 -1000 Message-ID: From: Brian Smith To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113cd2b01f5314052784e6a5 Archived-At: Cc: "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Dec 2015 23:23:57 -0000 --001a113cd2b01f5314052784e6a5 Content-Type: text/plain; charset=UTF-8 Martin Thomson wrote: > Watson Ladd wrote: > > Textbook DH does not ensure contributory behavior. Applications don't > > implement the required checks for poorly designed protocols. If we insert > > checks, applications which fail to make those checks will be vulnerable, > > while fixing protocols closes the hole. > > I've done a fair bit of reading into this issue as well, finding > Thai's blog posting and a few other things. As Watson says, the > protocol can be designed so that it doesn't depend on the DH exchange > providing contributory behaviour. We should definitely do that either > way. > TLS 1.2 and earlier versions are already defined. So, fixing the protocol is a good solution for TLS 1.3 and later, but draft-ietf-tls-curve25519 also is supposed to work for the versions that can't be fixed. > I understand that the checks are considered onerous by some, but I > still don't understand why anyone might refuse to do them. Checking > that you don't get a bad output from the DH computation is a tiny > piece of code that takes almost no time at all, even if you have to > worry about doing it in constant time. > To be clear, I'm not arguing that the draft should recommend or require such a check. Merely, I'm pointing out that we have the following contradictions that the draft doesn't resolve: 1. The draft says that Curve25519 doesn't require public key validation, full stop. 2. DJB said that Curve25519 may require public key validation for protocols that require contributory behavior. 3. Thai and Watson both said that TLS 1.2 and earlier require contributory behavior. It may be the case that TLS requires contributory behavior and point validation is still unnecessary. Or, it may be the case that TLS doesn't really require contributory behavior (though, it seems obvious to me that it does, at least for TLS 1.2 and earlier). Or, it may be the case that TLS requires contributory behavior and a check is necessary. The draft should make it clear which case we are dealing with, with a reference to the reasoning that gave us whatever conclusion is reached, but currently that is missing. Cheers, Brian -- https://briansmith.org/ --001a113cd2b01f5314052784e6a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Thomson <martin.thomson@gmail.com> wrote:
Watson Ladd <watsonbladd@gmail.com> wrote:
> Textbook DH does not ensure contributory behavior. Applications don= 9;t
> implement the required checks for poorly designed protocols. If we ins= ert
> checks, applications which fail to make those checks will be vulnerabl= e,
> while fixing protocols closes the hole.

I've done a fair bit of reading into this issue as well, finding=
Thai's blog posting and a few other things.=C2=A0 As Watson says, the protocol can be designed so that it doesn't depend on the DH exchange providing contributory behaviour.=C2=A0 We should definitely do that either=
way.

TLS 1.2 and earlier versions are a= lready defined. So, fixing the protocol is a good solution for TLS 1.3 and = later, but draft-ietf-tls-curve25519 also is supposed to work for the versi= ons that can't be fixed.
=C2=A0
I under= stand that the checks are considered onerous by some, but I
still don't understand why anyone might refuse to do them.=C2=A0 Checki= ng
that you don't get a bad output from the DH computation is a tiny
piece of code that takes almost no time at all, even if you have to
worry about doing it in constant time.

To be clear, I'= m not arguing that the draft should recommend or require such a check. Mere= ly, I'm pointing out that we have the following contradictions that the= draft doesn't resolve:

1. The draft says that Curve25519 doesn't require= public key validation, full stop.
2. DJB s= aid that Curve25519 may require public key validation for protocols that re= quire contributory behavior.
3. Thai and Wa= tson both said that TLS 1.2 and earlier require contributory behavior.

It may be = the case that TLS requires contributory behavior and point validation is st= ill unnecessary. Or, it may be the case that TLS doesn't really require= contributory behavior (though, it seems obvious to me that it does, at lea= st for TLS 1.2 and earlier). Or, it may be the case that TLS requires contr= ibutory behavior and a check is necessary. The draft should make it clear w= hich case we are dealing with, with a reference to the reasoning that gave = us whatever conclusion is reached, but currently that is missing.

Cheers,
Brian
--
<= /div>
--001a113cd2b01f5314052784e6a5-- From nobody Tue Dec 22 15:29:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9FBC1AC3B1 for ; Tue, 22 Dec 2015 15:29:28 -0800 (PST) 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 sMu11uSdTlqO for ; Tue, 22 Dec 2015 15:29:27 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B991AC3AE for ; Tue, 22 Dec 2015 15:29:27 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id 186so204211990iow.0 for ; Tue, 22 Dec 2015 15:29:27 -0800 (PST) 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=BYhBn00rFnIkC8PvFwUkwPKz9gE8YTw8QTBfOuiGS5Y=; b=scLwRz83aJXdh6n0GCl4n5DvVcNXjgV15eZx6zcD7wEAENalsYGKRL+v3yxxSCkTRT dV1olFUIfK4wO6E3PAtQf7icjEEJtiJPzQlZllhHex8LuB7Y6aj/tPEnYFIwyo1O5N68 rRibQiuNoiTNQUmzluSRJzC9wlrj7GpYlAp8l6GhP+udltIccyP6xVDUkFR8Q2Hv+R51 o93C2alemAOQOKFKlpgEk+aF/VGKzPSSfN97HdnOxUbxsnLX9WRFT1sLRWxYmlLYPc01 kv71a2uJYXsQCO4jBOhkmSBhoAnJhSLewPwhXx80EzHXlKlCM1WuaIEftl0ia8ghwo54 VLow== MIME-Version: 1.0 X-Received: by 10.107.131.40 with SMTP id f40mr16290624iod.190.1450826967092; Tue, 22 Dec 2015 15:29:27 -0800 (PST) Received: by 10.36.149.130 with HTTP; Tue, 22 Dec 2015 15:29:27 -0800 (PST) In-Reply-To: References: Date: Wed, 23 Dec 2015 10:29:27 +1100 Message-ID: From: Martin Thomson To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Dec 2015 23:29:29 -0000 On 23 December 2015 at 10:23, Brian Smith wrote: > It may be the case that TLS requires contributory behavior and point > validation is still unnecessary. Or, it may be the case that TLS doesn't > really require contributory behavior (though, it seems obvious to me that it > does, at least for TLS 1.2 and earlier). Or, it may be the case that TLS > requires contributory behavior and a check is necessary. The draft should > make it clear which case we are dealing with, with a reference to the > reasoning that gave us whatever conclusion is reached, but currently that is > missing. My understanding is that with session hash TLS 1.2 is OK, as is 1.3. Like Watson and Thai, I think that 1.2 without session hash is not OK. That suggests that the 25519 draft should require session hash in 1.2. From nobody Tue Dec 22 16:09:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B91B1AC444 for ; Tue, 22 Dec 2015 16:09:34 -0800 (PST) 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, 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 c2pUCdhR62BR for ; Tue, 22 Dec 2015 16:09:33 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3311AC447 for ; Tue, 22 Dec 2015 16:09:33 -0800 (PST) Received: by mail-ob0-x22e.google.com with SMTP id 18so155839329obc.2 for ; Tue, 22 Dec 2015 16:09:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gwQXe2m1DCpkMfp9q/vqGTE/IRS4deyG1gXWv3NtvjM=; b=b+eENS2C35r/X7/T2bas8H+ribDwff/Ti7sMSc6sNSGxBKtkpw0eX/C66mY9rgC6Em UDdlDmwHbWwNKTIFAj/HdLcI4I4PxF0HhOgFf6+y/9rOrMAmHkbqEM06Rwk7SU68cFeW NeeYcUrOM5L77ydP06LDNKy8gQblC9lg9yZNrUvJGqffA7P5jqw7loAYj9dgxckWEgZp 6vvzfhIUr03d0LsIfvgNOv2ApWvtVNZzluNIITd+nB/ZVXpuxYabTBACz62BQI4C95SO 5bduObMuAYzZtfFVEjtib04H6Cc6Q6UccBgifoWFJKjJNBrsx++HR5/P9csIX3nGZeyD PxQQ== 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=gwQXe2m1DCpkMfp9q/vqGTE/IRS4deyG1gXWv3NtvjM=; b=jTvbaEX3Qg9u+GHj7lEpLQYUPIWR6kVwRhUFPq2XWBXByyxjzZcRXNPLEFaEG7UBoH aiql5U+2aqWpOIEVKKQDxlNVTnVGPqQVAa2G2HxWsHeDJxMLDNOiOJ8JrZmAQGkpvDqF ktclCKev72hq+vGZwD+Etkb8HGJe7vTKbcyHROSJOuxF/O0jFCy+0iwshIBMGxAi5JVT nWl/JcSdUDsGRWsZOcykMeoRjDZBCkfl5+uXHlZ/JvXgS9Gcu2guWGESVPSRu83cxItH lriBs4px/gXt0ewuNUkrxRq+rgl7sX1Bcn7V4owQ4IkTGj+qWPuEmrN0qKt1o6VGEb4r fdSw== X-Gm-Message-State: ALoCoQlZQkRBjPKiSQ0z8EifhEShuAYMjnGJOjE8e/Gau3L/lJ6HszKT5+vKaVQ6fHQecVIytf3G8rfxW5y96xfZNkRzJtItlQ== MIME-Version: 1.0 X-Received: by 10.60.150.237 with SMTP id ul13mr12945055oeb.49.1450829372470; Tue, 22 Dec 2015 16:09:32 -0800 (PST) Received: by 10.76.62.8 with HTTP; Tue, 22 Dec 2015 16:09:32 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Dec 2015 14:09:32 -1000 Message-ID: From: Brian Smith To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b44fcc0604f6c052785891c Archived-At: Cc: "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Dec 2015 00:09:34 -0000 --047d7b44fcc0604f6c052785891c Content-Type: text/plain; charset=UTF-8 Martin Thomson wrote: > On 23 December 2015 at 10:23, Brian Smith wrote: > > It may be the case that TLS requires contributory behavior and point > > validation is still unnecessary. Or, it may be the case that TLS doesn't > > really require contributory behavior (though, it seems obvious to me > that it > > does, at least for TLS 1.2 and earlier). Or, it may be the case that TLS > > requires contributory behavior and a check is necessary. The draft should > > make it clear which case we are dealing with, with a reference to the > > reasoning that gave us whatever conclusion is reached, but currently > that is > > missing. > > My understanding is that with session hash TLS 1.2 is OK, as is 1.3. > Like Watson and Thai, I think that 1.2 without session hash is not OK. > > That suggests that the 25519 draft should require session hash in 1.2. > If an implementation only implements ECDHE cipher suites then implementing the session hash extension is not necessary, according to RFC 7627. I believe there are also a few other factors that would implementing the session hash extension to be unnecessary. If checking that the shared value isn't zero is sufficient, and/or blacklisting the public values that DJB mentions in [1] is sufficient, either would be better than mandating the implementation of the session hash extension just for this purpose. [1] http://cr.yp.to/ecdh.html#validate Cheers, Brian -- https://briansmith.org/ --047d7b44fcc0604f6c052785891c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Thomson <martin.thomson@gmail.com> wrote:
On 23 December 2015 at 10:23, Brian Smith <brian@briansmith.org>= wrote:
> It may be the case that TLS requires contributory behavior and point > validation is still unnecessary. Or, it may be the case that TLS doesn= 't
> really require contributory behavior (though, it seems obvious to me t= hat it
> does, at least for TLS 1.2 and earlier). Or, it may be the case that T= LS
> requires contributory behavior and a check is necessary. The draft sho= uld
> make it clear which case we are dealing with, with a reference to the<= br> > reasoning that gave us whatever conclusion is reached, but currently t= hat is
> missing.

My understanding is that with session hash TLS 1.2 is OK, as is 1.3.=
Like Watson and Thai, I think that 1.2 without session hash is not OK.

That suggests that the 25519 draft should require session hash in 1.2.

If an implementation only implements=C2=A0ECDHE cipher suites then impleme= nting the session hash extension is not necessary, according to=C2=A0RFC 7627. I be= lieve there are also a few other factors that would implementing the sessio= n hash extension to be unnecessary.

If checking that the shared value isn't zer= o is sufficient, and/or blacklisting the public values that DJB mentions in= [1] is sufficient, either would be better than mandating the implementatio= n of the session hash extension just for this purpose.
<= div class=3D"gmail_extra">
[1]=C2=A0http://cr.yp.to/ecdh.html#validate=

Cheers,
Brian
--
--047d7b44fcc0604f6c052785891c-- From nobody Tue Dec 22 17:13:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C47A1ACE30 for ; Tue, 22 Dec 2015 17:13:06 -0800 (PST) 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 7_V6oezJpsKj for ; Tue, 22 Dec 2015 17:13:05 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED7941AC40B for ; Tue, 22 Dec 2015 17:13:04 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 07F45284AED; Wed, 23 Dec 2015 01:13:04 +0000 (UTC) Date: Wed, 23 Dec 2015 01:13:03 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151223011303.GP18704@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.24 (2015-08-30) Archived-At: Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? 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, 23 Dec 2015 01:13:06 -0000 On Tue, Dec 22, 2015 at 02:09:32PM -1000, Brian Smith wrote: > If checking that the shared value isn't zero is sufficient It should suffice, ideally with a constant-time comparison. -- Viktor. From nobody Tue Dec 22 17:32:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DE51AD1DB for ; Tue, 22 Dec 2015 17:32:09 -0800 (PST) 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 ZIi8jyvjZ2GU for ; Tue, 22 Dec 2015 17:32:08 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75781AD0D7 for ; Tue, 22 Dec 2015 17:32:08 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id o67so203296038iof.3 for ; Tue, 22 Dec 2015 17:32:08 -0800 (PST) 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=zkyTqZ9uplgMYX1goItJBp4yDkiWGtHi8c99XkwjBog=; b=kHbH307yQ/9/Ujh5J+LzgV1ML6MyFNkdlUeACP+e36KQ7mt8y9ioOpF/zg5u1NvCX1 SVzQX2ebqHeM2SRz61Zl+9/APmUHTqBR8igIjRq1wOIG+j42eata9njfniCQtBv6s1vi WPUHbFX7oPCOn//sUhzLWpsj5mC+K9x9mBIyWtQYROUdKv18naWldQ2Ck0Yvk256VacG S+/8NrOteI1RVINE4kUh40u8xb5pv4miV5ba6+LXTIavR+FQQYmEvnjurErfQ3tJj1yR 4qmF1l+z0+LLpU1UpfGWgsCn0GeCo2VI7kzC8qUKLH2G5wtiPBz72sYNijgiZQzidei6 5D/w== MIME-Version: 1.0 X-Received: by 10.107.131.40 with SMTP id f40mr16744954iod.190.1450834328310; Tue, 22 Dec 2015 17:32:08 -0800 (PST) Received: by 10.36.149.130 with HTTP; Tue, 22 Dec 2015 17:32:08 -0800 (PST) In-Reply-To: References: Date: Wed, 23 Dec 2015 12:32:08 +1100 Message-ID: From: Martin Thomson To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Dec 2015 01:32:10 -0000 On 23 December 2015 at 11:09, Brian Smith wrote: > If an implementation only implements ECDHE cipher suites then implementing > the session hash extension is not necessary, according to RFC 7627. I It doesn't really say that as far as I can see, though I guess that you could infer that from this statement: Handshakes using Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) ciphersuites are also vulnerable if they allow arbitrary explicit curves or use curves with small subgroups. From nobody Wed Dec 23 01:50:54 2015 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 382521ACE24; Wed, 23 Dec 2015 01:50:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151223095051.6919.52944.idtracker@ietfa.amsl.com> Date: Wed, 23 Dec 2015 01:50:51 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-cached-info-21.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: Wed, 23 Dec 2015 09:50:51 -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 : Transport Layer Security (TLS) Cached Information Extension Authors : Stefan Santesson Hannes Tschofenig Filename : draft-ietf-tls-cached-info-21.txt Pages : 18 Date : 2015-12-21 Abstract: Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA). This document defines an extension that allows a TLS client to inform a server of cached information, allowing the server to omit already available information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-cached-info-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-cached-info-21 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 Wed Dec 23 11:54:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2149C1A1A14 for ; Wed, 23 Dec 2015 11:54:40 -0800 (PST) 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 yPowxVoI39yK for ; Wed, 23 Dec 2015 11:54:38 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A6511A1A0C for ; Wed, 23 Dec 2015 11:54:38 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id k189so164255095qkc.0 for ; Wed, 23 Dec 2015 11:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=s4yAYLHR4EcN35LFE5NhZoMnf0WdhK1GAXM/rzesg1k=; b=kxZE0CakvIAxQVZhcwiqK+eLSA7ukM8AbWksWN4Zf44aDVe6Hs6mTd28w/VyjqENP8 8TLFoBknWLakheWd4knpqEXgWH3pjSaEmzPrIloW6SuV4//MJ0DEiBmk/Y0YmuYvcT+N F46+and1DY9QPSKC06/nbNvJbDlrlWDMVRTYs1vt5FoGyW4Iu+znGoPwJ6PuyhNQ4H1x oqYXfwIGwn4qCh1vGqnw0n2/QTQNfBRKh2GXIVqhwQKLO7z26j5K7Gy9TlIlixCgcJZA Ice60TWZWncEmbpm3ATYNwY+B9eOmO7E5TkTYmQdfYUSOdelPLGdHqbGH1+jzCvTZl46 IEGg== X-Received: by 10.55.80.132 with SMTP id e126mr42341948qkb.17.1450900477784; Wed, 23 Dec 2015 11:54:37 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id g132sm18560453qhc.46.2015.12.23.11.54.37 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 23 Dec 2015 11:54:37 -0800 (PST) From: Dave Garrett To: tls@ietf.org, Hannes Tschofenig Date: Wed, 23 Dec 2015 14:54:35 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <564F2B3D.9000901@cs.tcd.ie> <5678546F.5060202@gmx.net> In-Reply-To: <5678546F.5060202@gmx.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201512231454.35859.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] AD review of /draft-ietf-tls-cached-info-20 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Dec 2015 19:54:40 -0000 On Monday, December 21, 2015 02:35:11 pm Hannes Tschofenig wrote: > On 11/20/2015 03:16 PM, Stephen Farrell wrote: > > - 2^16-1 CachedObject instances makes no sense at all, that would be > > bigger than the full handshake. Why not pick a sensible value? Even > > if you don't put such a value in the syntax, you could at least say > > that e.g. N instances will likely be pointless, for whatever N > > (10-ish?) would make the h/w bigger overall. > > That's indeed a bit large. I reduced it to 1..2^8-1. You need to reduce the max size of hash_value by two now, too. Now that CachedInformation is a max of 255 bytes, hash_value+type has to be a max of 255, thus hash_value can have a max of 253 with CachedInformationType being one byte and the length of hash_value being another byte. Reading the design in full, I think it might be a better idea to just set a fixed size for hash_value instead of using a variable size vector. Your design only relies on collision resistance of the hash and are truncating to 32-bit. I would simply set the hash_value size to a fixed 4 bytes and state that future hash algorithms used MUST NOT have a collision resistance worse than SHA256 when truncated to 4 bytes, which seems like a perfectly reasonable requirement to me. Switching to a fixed size structure has a few benefits: 1) Smaller, as you don't need to send lengths anymore. 2) Simpler to iterate through a client's CachedInformation if needed, as all entries are of the same size. 3) More clear spec, as the struct definition directly reflects how things are actually going to be used, rather than over generalizing. Dave From nobody Wed Dec 23 14:19:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C7A1A887D for ; Wed, 23 Dec 2015 14:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_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 vwJR-Giunp6V for ; Wed, 23 Dec 2015 14:19:13 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0124.outbound.protection.outlook.com [207.46.100.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6858A1A8877 for ; Wed, 23 Dec 2015 14:19:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PqCshwHXmvEWcxk/KxzzrWP4G99bWp7FL26HB86lk4E=; b=INYywNvpjy0x3thT5GSjTv0VHpuZzdsbPmmsdcQ3HBqRbfHGFgMiwmSCtIE2V6kFLDJwOqVY/uSSCFguZ9VC9jY5hIkxAO2yFiEk4P1by6Bno5shy+tuqpCg4UOPpCulmmBqJHxQOb1Kao6RW6+Ijcym5LJZnc+b+MeSTHDbxIk= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 23 Dec 2015 22:19:11 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0361.006; Wed, 23 Dec 2015 22:19:11 +0000 From: Christian Huitema To: "tls@ietf.org" Thread-Topic: A small detail in HMAC key generation for Finished message Thread-Index: AdE9zLUIRqzr9WCoSK+Y1yfu8/UHSA== Date: Wed, 23 Dec 2015 22:19:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [2601:600:8900:31e1:dd84:ed7c:8cb:cd28] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0655; 5:Z2csYxNJxyUqJKVKPrhllQGmijeFZ5/U/y/kyVweyaG8maO7z7SXafIFw6h7m5S1SJ0dAn979rV0ODle7qIn0iZEb3V/DNtL40nuh9Ml0kOPm1VqgVTHG2zPsVaojX2KkVoV7B5gFRhQjtScqGPKYQ==; 24:F/au1JBnkXMpuq5ewcleKYbQcdbiMuMZYawRsOwO1jGY74jLHKthKrp/n7ie35m/Er3ME1Ist0/D1ZQCCbG2wVepyCNUWbA+LULPgwOliWY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0655; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:DM2PR0301MB0655; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655; x-forefront-prvs: 0799B1B2D7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(1730700002)(74316001)(5008740100001)(10400500002)(10290500002)(54356999)(40100003)(122556002)(33656002)(99286002)(106356001)(110136002)(5001960100002)(107886002)(105586002)(86612001)(86362001)(189998001)(10090500001)(50986999)(97736004)(81156007)(101416001)(6116002)(8990500004)(2351001)(229853001)(87936001)(2900100001)(77096005)(102836003)(92566002)(11100500001)(5005710100001)(5004730100002)(586003)(5002640100001)(1096002)(1220700001)(450100001)(5003600100002)(2501003)(76576001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0655; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2015 22:19:11.0279 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0655 Archived-At: Subject: [TLS] A small detail in HMAC key generation for Finished message X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Dec 2015 22:19:15 -0000 In the current 1.3 draft, section 6.3.4.3 specifies the content of the Fini= shed message. It contains this specification for key computation: client_finished_key =3D HKDF-Expand-Label(BaseKey, "client finished", "", L) server_finished_key =3D HKDF-Expand-Label(BaseKey, "server finished", "", L) I wonder what the zero length string actually means. Is it a null-terminate= d string that would encode in binary as a one octet byte string of value 0,= or an empty string that would encode in binary as a zero length string? There is one example of encoding a string in section 4.8.1, and the binary = representation shows the encoding of the final null byte. Is that a common = assumption? Similarly, in the HKDF-Expand-Label, do we assume a final null byte for the= "label"? -- Christian Huitema From nobody Wed Dec 23 15:05:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D281A891E for ; Wed, 23 Dec 2015 15:05:37 -0800 (PST) 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, HTML_MESSAGE=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 gKuhvIIOTh43 for ; Wed, 23 Dec 2015 15:05:35 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25501A891D for ; Wed, 23 Dec 2015 15:05:35 -0800 (PST) Received: by mail-yk0-x22e.google.com with SMTP id x184so210082192yka.3 for ; Wed, 23 Dec 2015 15:05:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=drXk5bmo4NqTDNJQRoqlEfBbdVmJWBupGpoegV9fDXE=; b=rUimjByWqvtKBavk8/dYX6xPkfkMzJOdtjhZlrvzDxihQBzPiyeKqaxg7ISB62/ZeN 4GmclUebqDW7GzKUEgQTtNxIW7DLI0jm74GBbAAKMZcUjHGo5b8jaQww/XJ05VDh53Wl QBsXF7Ao3US/MdtzKE8fxoIqumWXXjiomajOGEmWkh6gdgvM+FRFe+F/Oekdcy2+tAin jic1+KmCvNQ4EqCOHNqkQdjNyphXNf/pWoxevnioAZleTmEVaZ7FnQeiGZ3nncLZl8t8 +Ypd+lChYciCNqqoMn6eDUi6vtAt/67OFl9HTNZ2Pt9jno+y7mDuXoUq9y7tETJ7cOJ0 64fA== 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=drXk5bmo4NqTDNJQRoqlEfBbdVmJWBupGpoegV9fDXE=; b=YqZsz/B/LVSt0BwW79TsRG2wMlyVb7J6ICWrO32rXgoWppt9IN2FIkikL0XJX83FoK N+l9E0JSKruu/js4YKseMA+ZgHNhGr4SBMyuZZrLSEU11MYOhZR6kg59MBYsFp6a6Jou 7Ahk2tO5spBRc8HI/UaEJHKXJ6MUwSGOXLZJAd1UELD2KNzpNCmJbmvJAuuQrdkQd6zX O6ijyY3y0HfDZiR7hGACY3dzJkaluTyUtpj/GH84Q5cFex9KReJDF1LOsWyQsSoFnFt7 ZZ830jWXEED/UpzhCU/zixOuL6TAOIqYHknjEaN3QHpvPtgiLnBH16fkJil/pb+z1IqJ 6B9A== X-Gm-Message-State: ALoCoQne0cWQSSDhRFsLqUQf2oYPOgT2oEpogkihCjaimIHf2T55/rQSMi/ayQNlTWRcrlShEP2IxGk7uknh3IHCjm/YQiaySw== X-Received: by 10.129.148.3 with SMTP id l3mr25791040ywg.155.1450911934974; Wed, 23 Dec 2015 15:05:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Wed, 23 Dec 2015 15:04:55 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 23 Dec 2015 15:04:55 -0800 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=94eb2c07c8bc7c326c052798c240 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A small detail in HMAC key generation for Finished message X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Dec 2015 23:05:37 -0000 --94eb2c07c8bc7c326c052798c240 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 23, 2015 at 2:19 PM, Christian Huitema wrote: > In the current 1.3 draft, section 6.3.4.3 specifies the content of the > Finished message. It contains this specification for key computation: > > client_finished_key = > HKDF-Expand-Label(BaseKey, "client finished", "", L) > > server_finished_key = > HKDF-Expand-Label(BaseKey, "server finished", "", L) > > I wonder what the zero length string actually means. Is it a > null-terminated string that would encode in binary as a one octet byte > string of value 0, or an empty string that would encode in binary as a zero > length string? > I see what you mean about the ambiguity here. What I meant was 0 bytes (i.e., no trailing '\0'). There is one example of encoding a string in section 4.8.1, and the binary > representation shows the encoding of the final null byte. Is that a common > assumption? > No. > Similarly, in the HKDF-Expand-Label, do we assume a final null byte for > the "label"? > No. I wonder if we should instead add the '\0' explicitly in the 4.8.1 for maximal clarity. -Ekr > -- Christian Huitema > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c07c8bc7c326c052798c240 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 23, 2015 at 2:19 PM, Christian Huitema &l= t;huitema@micros= oft.com> wrote:
In the curr= ent 1.3 draft, section 6.3.4.3 specifies the content of the Finished messag= e. It contains this specification for key computation:

client_finished_key =3D
=C2=A0 =C2=A0 HKDF-Expand-Label(BaseKey, "client finished", "= ;", L)

server_finished_key =3D
=C2=A0 =C2=A0 HKDF-Expand-Label(BaseKey, "server finished", "= ;", L)

I wonder what the zero length string actually means. Is it a null-terminate= d string that would encode in binary as a one octet byte string of value 0,= or an empty string that would encode in binary as a zero length string?

I see what you mean about the ambiguity h= ere. What I meant was 0 bytes
(i.e., no trailing '\0').



There is one example of encoding a string in section 4.8.1, and the binary = representation shows the encoding of the final null byte. Is that a common = assumption?

No.

=C2=A0
Similarly, in the HKDF-Expand-Label, do we assume a final null byte for the= "label"?

No. I wonder if we = should instead add the '\0' explicitly in the 4.8.1 for maximal cla= rity.
-Ekr


-- Christian Huitema

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

--94eb2c07c8bc7c326c052798c240-- From nobody Wed Dec 23 17:05:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E6D1A8A90 for ; Wed, 23 Dec 2015 17:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_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 nbgHiMkXTtKp for ; Wed, 23 Dec 2015 17:05:01 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0119.outbound.protection.outlook.com [207.46.100.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E231A8A8D for ; Wed, 23 Dec 2015 17:05:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=c1Sv3w+4vwviVghx0T3kglQlqOo/Yn8cjXpKjSlXh9w=; b=cyuZhsiixpJURXwnlB9hXaq9mTwDxJ3RBww2hGvaZwh7CHCcREE7BWaQneuoq1iir5/T9KgI9ramFUgbh45zed8CEmj9vJnWuCeT80f9AMbHmd8WLN2oAEv7e5iLwD6UjZHck08YDEaAcE3DjdKTBub1DgL0ZX+QXScJ2aMjo5U= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) with Microsoft SMTP Server (TLS) id 15.1.361.13; Thu, 24 Dec 2015 01:04:59 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0361.006; Thu, 24 Dec 2015 01:04:59 +0000 From: Christian Huitema To: Eric Rescorla Thread-Topic: [TLS] A small detail in HMAC key generation for Finished message Thread-Index: AdE9zLUIRqzr9WCoSK+Y1yfu8/UHSAACaE6AAAQTZqA= Date: Thu, 24 Dec 2015 01:04:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [2601:600:8900:31e1:dd84:ed7c:8cb:cd28] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0655; 5:YeKhLQ+hso3rNIl7Df3DNSR8qL/TYk+BN32FnggvgejKbJKJeTNDmMUEW9FtOlz8SbKXjBXWWJS9Unowak1D1gVgu2h1NCgLaTcHHTPtV8KFSgynpQ1Lwggjsbyjp3dsuRr5tFq0giLU+4Hh4OmVVA==; 24:goZPs7KXpWenVnI6Hpba8rSrElcz9zNaNTsTi9U2w76Wa6rKCPQ7PLlK8dKNxl7PrawS21UnuWJ8vdjiR4q37XhXmwgOUfaaXmNxu38qTXU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0655; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:DM2PR0301MB0655; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655; x-forefront-prvs: 0800C0C167 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(54094003)(377454003)(189002)(199003)(24454002)(77096005)(5004730100002)(5005710100001)(586003)(92566002)(11100500001)(102836003)(2950100001)(6116002)(101416001)(87936001)(2900100001)(8990500004)(76576001)(5003600100002)(5002640100001)(1096002)(1220700001)(40100003)(10290500002)(33656002)(122556002)(10400500002)(5008740100001)(74316001)(54356999)(50986999)(86362001)(189998001)(97736004)(81156007)(76176999)(10090500001)(106356001)(99286002)(105586002)(86612001)(110136002)(5001960100002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0655; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2015 01:04:59.4453 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0655 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A small detail in HMAC key generation for Finished message X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Dec 2015 01:05:03 -0000 T24gV2VkbmVzZGF5LCBEZWNlbWJlciAyMywgMjAxNSAzOjA1IFBNLCBFcmljIFJlc2NvcmxhIHdy b3RlOg0KPj4gSSB3b25kZXIgd2hhdCB0aGUgemVybyBsZW5ndGggc3RyaW5nIGFjdHVhbGx5IG1l YW5zLiBJcyBpdCBhIG51bGwtdGVybWluYXRlZCBzdHJpbmcgDQo+PiB0aGF0IHdvdWxkIGVuY29k ZSBpbiBiaW5hcnkgYXMgYSBvbmUgb2N0ZXQgYnl0ZSBzdHJpbmcgb2YgdmFsdWUgMCwgb3IgYW4g ZW1wdHkgDQo+PiBzdHJpbmcgdGhhdCB3b3VsZCBlbmNvZGUgaW4gYmluYXJ5IGFzIGEgemVybyBs ZW5ndGggc3RyaW5nPw0KPg0KPiBJIHNlZSB3aGF0IHlvdSBtZWFuIGFib3V0IHRoZSBhbWJpZ3Vp dHkgaGVyZS4gV2hhdCBJIG1lYW50IHdhcyAwIGJ5dGVzDQo+IChpLmUuLCBubyB0cmFpbGluZyAn XDAnKS4NCg0KT0ssIG1ha2VzIHNlbnNlLg0KDQo+PiBUaGVyZSBpcyBvbmUgZXhhbXBsZSBvZiBl bmNvZGluZyBhIHN0cmluZyBpbiBzZWN0aW9uIDQuOC4xLCBhbmQgdGhlIGJpbmFyeSByZXByZXNl bnRhdGlvbg0KPj4gc2hvd3MgdGhlIGVuY29kaW5nIG9mIHRoZSBmaW5hbCBudWxsIGJ5dGUuIElz IHRoYXQgYSBjb21tb24gYXNzdW1wdGlvbj8NCj4NCj4gTm8uDQo+DQo+PiBTaW1pbGFybHksIGlu IHRoZSBIS0RGLUV4cGFuZC1MYWJlbCwgZG8gd2UgYXNzdW1lIGEgZmluYWwgbnVsbCBieXRlIGZv ciB0aGUgImxhYmVsIj8NCj4NCj4gTm8uIEkgd29uZGVyIGlmIHdlIHNob3VsZCBpbnN0ZWFkIGFk ZCB0aGUgJ1wwJyBleHBsaWNpdGx5IGluIHRoZSA0LjguMSBmb3IgbWF4aW1hbCBjbGFyaXR5Lg0K DQpFaXRoZXIgdGhhdCwgb3IganVzdCByZW1vdmUgdGhlIHRyYWlsaW5nIDAwIGZyb20gdGhlIGJp bmFyeSBkZXNjcmlwdGlvbi4NCg0KLS0gQ2hyaXN0aWFuIEh1aXRlbWENCg0K From nobody Thu Dec 24 02:36:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0453F1B2A0F for ; Thu, 24 Dec 2015 02:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-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 6ElxwqZA3ss0 for ; Thu, 24 Dec 2015 02:36:40 -0800 (PST) Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34F61B2A0D for ; Thu, 24 Dec 2015 02:36:40 -0800 (PST) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id tBOAaeH8005858; Thu, 24 Dec 2015 05:36:40 -0500 Date: Thu, 24 Dec 2015 05:36:39 -0500 (EST) From: Nikos Mavrogiannopoulos To: Hubert Kario Message-ID: <2076706193.1079823.1450953399677.JavaMail.zimbra@redhat.com> In-Reply-To: <3293494.XPNSX3av0N@pintsize.usersys.redhat.com> References: <3293494.XPNSX3av0N@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.10.56.150] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF43 (Linux)/8.0.6_GA_5922) Thread-Topic: PRF digest function for ChaCha20-Poly1305 cipher suites Thread-Index: 4z+HhNxt8YYDvtt+aPbp+68u5bnECQ== Archived-At: Cc: Adam Langley , tls@ietf.org Subject: Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Dec 2015 10:36:42 -0000 ----- Original Message ----- > I'm not convinced about SHA-512, but yes, they probably should use > SHA-384 at the very least. And given that the algorithm for SHA-384 and > SHA-512 is essentially the same, using just different IVs, that should > be usable for highly restricted hardware, wouldn't it? > I would be against SHA-512 as that would be the very first cipher that > uses SHA-512 PRF in TLS1.2, making its addition/implementation much more > invasive to the underlying library, OTOH, we have multiple ciphers which > use SHA-384 PRF. I think I just need to remind the delay after which NSS > added support for SHA-384 compared to introduction to AES-128-GCM TLS > ciphers... I agree. SHA384 also aligns it with the AES-256-GCM ciphers. I believe an implementation mixing chacha20 with AES is a much more common scenario than the one described by Brian. regards, Nikos From nobody Thu Dec 24 12:40:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C569F1A1EF3 for ; Thu, 24 Dec 2015 12:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 u1Gy-ZALegFT for ; Thu, 24 Dec 2015 12:40:50 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431821A1EF5 for ; Thu, 24 Dec 2015 12:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Lee3CfiVQe+c+c246d/72tAPhvSO1jCZB605LviO4KI=; b=PHQHMrFuhOJ4DCbyBucEyEBchaEeZvHtZcdp4p0RfWoy6YZvZOCBdNdiUY565VlauoOY+S448sSSac6iASmfdTAExG0CftntZCrB5yMFqd6c7COKxjmnNOnKPKfi6Yh6JpHRuwf9u8+DhYTMB/OKo5Yz1ds/h4uHcxizo24sSfA= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) with Microsoft SMTP Server (TLS) id 15.1.361.13; Thu, 24 Dec 2015 20:40:27 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0361.006; Thu, 24 Dec 2015 20:40:27 +0000 From: Christian Huitema To: Martin Thomson Thread-Topic: [TLS] What does it mean to not include 0-RTT message in the handshake hash? Thread-Index: AdE8WUzTusUbdu5EQyy4pojDDNAspQAA40EAAACQIQAAAGOBgACJ8x0A Date: Thu, 24 Dec 2015 20:40:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [2601:600:8900:31e1:bd1a:2cd1:8ab4:db94] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0655; 5:i4m8T8LBetRuySsu4xmiC1uMFOMDoEAKuLzS7qYz5LPOGDuoruxWqKWBMzFC7R7SZodicXKdzAucBCSUHvZvurCerhtK5NXCZvPI5EwoLjbbIckX/OEmmYzuGu/zVOohG4L5RF5JoWzVcjRvWtZR0g==; 24:JGlXiqO6eJw/P7DvKR4dSx5S+Xwk/ltT7nKdJbY9Jc9IEoc2dXexgoZs9F7PJOnikRgUdx28hy4Q4G4LDfPtoeTp/4IDRNtsf9FQd4rne6A= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0655; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:DM2PR0301MB0655; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655; x-forefront-prvs: 0800C0C167 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(199003)(24454002)(110136002)(77096005)(5001960100002)(5004730100002)(586003)(92566002)(102836003)(5005710100001)(11100500001)(101416001)(76576001)(2950100001)(6116002)(87936001)(8990500004)(2900100001)(1096002)(1220700001)(5003600100002)(5002640100001)(40100003)(33656002)(19580405001)(10290500002)(19580395003)(122556002)(10400500002)(50986999)(5008740100001)(74316001)(54356999)(93886004)(189998001)(81156007)(97736004)(86362001)(10090500001)(99286002)(76176999)(86612001)(106356001)(105586002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0655; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2015 20:40:26.8212 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0655 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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: Thu, 24 Dec 2015 20:40:54 -0000 T24gTW9uZGF5LCBEZWNlbWJlciAyMSwgMjAxNSA2OjMwIFBNLCBNYXJ0aW4gVGhvbXNvbiB3cm90 ZToNCj4gDQo+IE9uIDIyIERlY2VtYmVyIDIwMTUgYXQgMTM6MjUsIENocmlzdGlhbiBIdWl0ZW1h IDxodWl0ZW1hQG1pY3Jvc29mdC5jb20+DQo+IHdyb3RlOg0KPiA+PiBVbmxlc3MgSSdtIGNvbmZ1 c2VkICh3aGljaCBpcyBwb3NzaWJsZSBnaXZlbiB0aGUgdGltZSBvZiBuaWdodCksDQo+ID4+IHRo ZSBpbnRlbnRpb24sIGFzIHlvdSBzYXksIGlzIHRvIHNlcGFyYXRlIG91dCB0aGUgMC1SVFQgaGFu ZHNoYWtlDQo+ID4+IG1lc3NhZ2VzIGkuZS4sIChjZXJ0LCBjZXJ0IHZlcmlmeSwgZmluaXNoZWQp IGZyb20gdGhlIDEtUlRUIGNvbXB1dGF0aW9ucy4NCj4gPg0KPiA+IE9LLiBUaGF0IGRvZXMgbm90 IHNpbXBsaWZ5IGltcGxlbWVudGF0aW9ucyB1c2luZyBydW5uaW5nIGhhc2hlcy4uLg0KPiANCj4g SXQgZG9lcyBpZiB5b3UgY29uc2lkZXIgdGhlIHBvc3NpYmlsaXR5IG9mIGhhdmluZyB0byBkcm9w IHRoZSAwLVJUVCBkYXRhLg0KDQpUaGF0J3MgcmlnaHQuIEluIGZhY3QsIGl0IG1heSBiZSBhIGdv b2QgaWRlYSB0byBhZGQgdG8gdGhlIHNwZWMgYSBkZXNjcmlwdGlvbiBvZiBhICJGYWlsZWQgMC1S VFQgaGFuZHNoYWtlLiIgSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgdGhlIGZvbGxvd2luZyB3 aWxsIGhhcHBlbjoNCg0KKiBTZXJ2ZXIgd2lsbCByZWNlaXZlIHRoZSBjbGllbnQgaGVsbG8sIGln bm9yZSB0aGUgRWFybHkgRGF0YSBJbmRpY2F0aW9uIGV4dGVuc2lvbiwgYW5kIHByb2NlZWQgYXMg aW4gMS1SVFQuDQoqIFNlcnZlciB3aWxsIGluZGljYXRlIHRoYXQgYnkgbm90IGFkZGluZyBhbiBF YXJseSBEYXRhIEluZGljYXRpb24gdG8gdGhlIHNlcnZlciBoZWxsby4NCiogU2VydmVyIHdpbGwg cmVjZWl2ZSBhIHNlcmllcyBvZiAwLVJUVCBtZXNzYWdlcyB0aGF0IGl0IGNhbm5vdCBkZWNpcGhl ciwgYW5kIGp1c3QgZHJvcCB0aGUgbWVzc2FnZXMuDQoqIENsaWVudCB3aWxsIHJlY2VpdmUgc2Vy dmVyIGhlbGxvLCBhbmQgcHJvY2VlZCBhcyBwZXIgMS1SVFQuIENsaWVudCBBUEkgd2lsbCBzaWdu YWwgdGhhdCAwLVJUVCBkYXRhIHdhcyBsb3N0LCBhcHBsaWNhdGlvbiBtYXkgZGVjaWRlIHRvIHJl dHJhbnNtaXQuDQoqIFNlcnZlciBtYXkgc2VuZCBjbGllbnQgYXV0aGVudGljYXRpb24gcmVxdWVz dHMuIENsaWVudCB3aWxsIGhhdmUgdG8gcmVwZWF0IHRoZSBhdXRoZW50aWNhdGlvbiBtZXNzYWdl cywgZXZlbiBpZiBpdCBhbHJlYWR5IHNlbnQgdGhlbSBhcyAwLVJUVC4NCg0KSW4gdGhhdCBzY2Vu YXJpbywgdGhlIGhhbmRzaGFrZSBoYXNoIGNhbm5vdCBpbmNsdWRlIHRoZSAwLVJUVCBtZXNzYWdl cywgc2luY2UgdGhlIHNlcnZlciBkb2VzIG5vdCBpbiBmYWN0IHJlY2VpdmUgdGhlbSwgYW5kIHRo ZXkgZG8gbm90IGNvbnRyaWJ1dGUgdG8gdGhlIHN0YXRlIG9mIHRoZSBjb25uZWN0aW9uLiANCg0K V2UgY2FuIG9mIGNvdXJzZSBkZWJhdGUgd2hldGhlciB0aGUgMC1SVFQgbWVzc2FnZXMgc2hvdWxk IGFsc28gbm90IGJlIGluY2x1ZGVkIGluIHRoZSBoYXNoIGlmIHRoZSAwLVJUVCBleGNoYW5nZSB3 YXMgc3VjY2Vzc2Z1bCwgdGhlIG1lc3NhZ2VzIHdlcmUgcmVjZWl2ZWQsIGFuZCB0aGV5IGNvbnRy aWJ1dGVkIHRvIHRoZSBzdGF0ZSBvZiB0aGUgY29ubmVjdGlvbi4gSWYgdGhleSBhcmUgbm90IGlu Y2x1ZGVkLCB0aGVuIHRoZSAiRmluaXNoZWQiIEhNQUMgZG9lcyBub3Qgb2ZmZXIgYSBwcm90ZWN0 aW9uIGFnYWluc3QgdGFtcGVyaW5nLiBUaGlzIG1heSBvcGVuIHRoZSBwb3NzaWJpbGl0eSBvZiBz b21lIGtpbmQgb2Ygc3Vic3RpdHV0aW9uIG9yIHJlcGxheSBhdHRhY2suDQoNClRoZSBmYWlsZWQg MC1SVFQgaGFuZHNoYWtlIHNjZW5hcmlvIGFsc28gaGFzIGludGVyZXN0aW5nIGNvbnNlcXVlbmNl cyBvbiB0aGUgUmVjb3JkIGxheWVyLiBXZSBoYXZlIGEgbGVnaXRpbWF0ZSBzY2VuYXJpbyBpbiB3 aGljaCByZWNlaXZlZCByZWNvcmRzIGNhbm5vdCBiZSBkZWNyeXB0ZWQuIFRoaXMgc2hvdWxkIG5v dCB0cmlnZ2VyIGFsYXJtcy4gQW5kIHRoZSBudW1iZXJpbmcgc2NoZW1lIHNob3VsZCBiZSByb2J1 c3QgYWdhaW5zdCB0aGVzZSBtaXNzaW5nIHJlY29yZHMuDQoNCi0tIENocmlzdGlhbiBIdWl0ZW1h DQoNCg0KDQoNCg0K From nobody Thu Dec 24 13:26:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE9D1A21A1 for ; Thu, 24 Dec 2015 13:26:46 -0800 (PST) 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 PPAjJ6hLoSzH for ; Thu, 24 Dec 2015 13:26:45 -0800 (PST) Received: from mail-qg0-x241.google.com (mail-qg0-x241.google.com [IPv6:2607:f8b0:400d:c04::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E77831A212A for ; Thu, 24 Dec 2015 13:26:44 -0800 (PST) Received: by mail-qg0-x241.google.com with SMTP id b35so4163071qge.2 for ; Thu, 24 Dec 2015 13:26:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=mmi3Homqqkc/8fuAWdzVaKB6UhhY73tHEsitSecAXTI=; b=k5f+UCKjJBKWKS0yhIqBhca8M8HlIwkdI1MwUY1JHXXK+CthclzW3eSXee5Bp1K2Jw 19f/EnJSSb/en8Ee7eXY1wN3Fea45AVHWlaWLWB9QPrVAOvNc1ojS1HzZUQhOc4qOqJP 1v9LpzshheH9gltVBBs/sTIX/T/SlLWjERwXWndMJD2wiDYl2YypJAv9/muQU0E9SCu5 iG7J3DSxA7nl+6fP6KIUHsDkiorXtGEKC+6pYWd9GUrakj9D1IhzmFajyE51FU6OAM93 sqfWw+joABg/7IqfMF7P3ELSUV6hX9sf92HDZjp9w+F1Exu7+mlKbgYXUMbM05FL+eOq DSrA== X-Received: by 10.140.246.195 with SMTP id r186mr54313646qhc.56.1450992404196; Thu, 24 Dec 2015 13:26:44 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id m13sm7069996qki.8.2015.12.24.13.26.43 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 24 Dec 2015 13:26:43 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Thu, 24 Dec 2015 16:26:41 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201512241626.41884.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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: Thu, 24 Dec 2015 21:26:47 -0000 On Thursday, December 24, 2015 03:40:26 pm Christian Huitema wrote: > On Monday, December 21, 2015 6:30 PM, Martin Thomson wrote: > > On 22 December 2015 at 13:25, Christian Huitema > > wrote: > > >> Unless I'm confused (which is possible given the time of night), > > >> the intention, as you say, is to separate out the 0-RTT handshake > > >> messages i.e., (cert, cert verify, finished) from the 1-RTT computations. > > > > > > OK. That does not simplify implementations using running hashes... > > > > It does if you consider the possibility of having to drop the 0-RTT data. > > That's right. In fact, it may be a good idea to add to the spec a description of a "Failed 0-RTT handshake." If I understand correctly, the following will happen: > > * Server will receive the client hello, ignore the Early Data Indication extension, and proceed as in 1-RTT. > * Server will indicate that by not adding an Early Data Indication to the server hello. > * Server will receive a series of 0-RTT messages that it cannot decipher, and just drop the messages. > * Client will receive server hello, and proceed as per 1-RTT. Client API will signal that 0-RTT data was lost, application may decide to retransmit. > * Server may send client authentication requests. Client will have to repeat the authentication messages, even if it already sent them as 0-RTT. > > In that scenario, the handshake hash cannot include the 0-RTT messages, since the server does not in fact receive them, and they do not contribute to the state of the connection. > > We can of course debate whether the 0-RTT messages should also not be included in the hash if the 0-RTT exchange was successful, the messages were received, and they contributed to the state of the connection. If they are not included, then the "Finished" HMAC does not offer a protection against tampering. This may open the possibility of some kind of substitution or replay attack. > > The failed 0-RTT handshake scenario also has interesting consequences on the Record layer. We have a legitimate scenario in which received records cannot be decrypted. This should not trigger alarms. And the numbering scheme should be robust against these missing records. Do we have anything that protects against an intermediary stripping 0RTT messages from a handshake to force a fallback? Could we just make the handshake hash use the encrypted messages, regardless of if it can decrypt them? (maybe for all messages?) Dave From nobody Thu Dec 24 13:44:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E35F1A6EDA for ; Thu, 24 Dec 2015 13:44:42 -0800 (PST) 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, HTML_MESSAGE=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 gFMCxeSJ1FqD for ; Thu, 24 Dec 2015 13:44:41 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E47A81A6ED9 for ; Thu, 24 Dec 2015 13:44:40 -0800 (PST) Received: by mail-yk0-x235.google.com with SMTP id p130so230421140yka.1 for ; Thu, 24 Dec 2015 13:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tsPcY96AoU9fb285sa+KZVhZFgke9UyxZZnnB12ooVM=; b=03L7IeUuwSf8X6sRwYLBoha2aW/gfAvwrggXdWLplqqvHeh0Eu8PkG32pb9bPxtDnX 7ixW6iVoApOjOWq/G327/yTi+WYYVmq8497b+7Gf3Q9AehPvlOtTWK266bb49HAHBF5l ljfOztNUL2B+VdzKDFz8pWGLm3drdfQTlNgqLCGhMN9VnhlOQdCutSNpKxBQMmX4AzwN IcQefFXN4poJ/UmoTRyd57uYyDPp9mYAHR2iK3pDto1YJUrJxqBmqrx90bEZqnUjdP0D oOwCQ0xIF1Kuu6G3CWAmrwHRUFznF/xj5I9kl1MAjKMX29wKsy/MTZ7c6XtBeRismxzl MvfA== 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=tsPcY96AoU9fb285sa+KZVhZFgke9UyxZZnnB12ooVM=; b=Mz35l0io4LCde9djwL7Mf4w/Rcf6LAYlufFczwYRN5xYHvdrqnMhZ5bJ0rUETaawXs 93DwrlDITKouq8dYw9VDiF61N+Vj7Rw5X3SWm07ttDZgSj0XMDy86FmmXNxi031WDMCK 5swP92YlEYAXggJawxX6Pf1ocD6WDXKKRoey9hLZL+zhoUC3Jjp8ow1DgKEquIr5R6vZ myqnkpQ7FjNl8HAt9pL4KoEivrc/uCVtY/+Zd6i0AKQO0NusoAzXzPGoEq5mYfG30Fw9 riFc/PBJTRxHzWguh3LBOOLBQxKfH8a2Ob6kNuuCx6ZanSSillB0EAXxfbai8bQzspma G9bQ== X-Gm-Message-State: ALoCoQkqlPZZsDPCLF3Yya9uyPZp5OTd4y9ROwzvNmdbmURFM74z6KuXEX86YpeFtpSjU/xx4q6fSzEW/5PsLq5eWWBoVT+Heg== X-Received: by 10.129.73.133 with SMTP id w127mr33059400ywa.223.1450993480215; Thu, 24 Dec 2015 13:44:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Thu, 24 Dec 2015 13:44:00 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 24 Dec 2015 16:44:00 -0500 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=001a114dcf6af603870527abbed9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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: Thu, 24 Dec 2015 21:44:42 -0000 --001a114dcf6af603870527abbed9 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 24, 2015 at 3:40 PM, Christian Huitema wrote: > On Monday, December 21, 2015 6:30 PM, Martin Thomson wrote: > > > > On 22 December 2015 at 13:25, Christian Huitema > > wrote: > > >> Unless I'm confused (which is possible given the time of night), > > >> the intention, as you say, is to separate out the 0-RTT handshake > > >> messages i.e., (cert, cert verify, finished) from the 1-RTT > computations. > > > > > > OK. That does not simplify implementations using running hashes... > > > > It does if you consider the possibility of having to drop the 0-RTT data. > > That's right. In fact, it may be a good idea to add to the spec a > description of a "Failed 0-RTT handshake." If I understand correctly, the > following will happen: > > * Server will receive the client hello, ignore the Early Data Indication > extension, and proceed as in 1-RTT. > * Server will indicate that by not adding an Early Data Indication to the > server hello. > * Server will receive a series of 0-RTT messages that it cannot decipher, > and just drop the messages. > * Client will receive server hello, and proceed as per 1-RTT. Client API > will signal that 0-RTT data was lost, application may decide to retransmit. > * Server may send client authentication requests. Client will have to > repeat the authentication messages, even if it already sent them as 0-RTT. > This seems exactly correct. In that scenario, the handshake hash cannot include the 0-RTT messages, > since the server does not in fact receive them, and they do not contribute > to the state of the connection. > Correct. We can of course debate whether the 0-RTT messages should also not be > included in the hash if the 0-RTT exchange was successful, the messages > were received, and they contributed to the state of the connection. If they > are not included, then the "Finished" HMAC does not offer a protection > against tampering. This may open the possibility of some kind of > substitution or replay attack. > They are included in the client's 0-RTT Finished, so as long as SS is not compromised, you should not be able to modify them. They are not protected against modifications if SS is compromised, whereas other messages are covered by the server's signature. The failed 0-RTT handshake scenario also has interesting consequences on > the Record layer. We have a legitimate scenario in which received records > cannot be decrypted. This should not trigger alarms. And the numbering > scheme should be robust against these missing records. Yes. Resetting the sequence number as proposed by Fournet et al. and in WIP-11 makes this easier. -Ekr --001a114dcf6af603870527abbed9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 24, 2015 at 3:40 PM, Christian Huitema &l= t;huitema@micros= oft.com> wrote:
On Monday, December 21, 2015 6:30 PM, Martin = Thomson wrote:
>
> On 22 December 2015 at 13:25, Christian Huitema <huitema@microsoft.com>
> wrote:
> >> Unless I'm confused (which is possible given the time of = night),
> >> the intention, as you say, is to separate out the 0-RTT hands= hake
> >> messages i.e., (cert, cert verify, finished) from the 1-RTT c= omputations.
> >
> > OK. That does not simplify implementations using running hashes..= .
>
> It does if you consider the possibility of having to drop the 0-RTT da= ta.

That's right. In fact, it may be a good idea to add to the = spec a description of a "Failed 0-RTT handshake." If I understand= correctly, the following will happen:

* Server will receive the client hello, ignore the Early Data Indication ex= tension, and proceed as in 1-RTT.
* Server will indicate that by not adding an Early Data Indication to the s= erver hello.
* Server will receive a series of 0-RTT messages that it cannot decipher, a= nd just drop the messages.
* Client will receive server hello, and proceed as per 1-RTT. Client API wi= ll signal that 0-RTT data was lost, application may decide to retransmit. * Server may send client authentication requests. Client will have to repea= t the authentication messages, even if it already sent them as 0-RTT.

This seems exactly correct.


In that scenario, the handshake hash cannot include the 0-RTT messages, sin= ce the server does not in fact receive them, and they do not contribute to = the state of the connection.

Correct.


We can of course debate whether the 0-RTT messages should also not be inclu= ded in the hash if the 0-RTT exchange was successful, the messages were rec= eived, and they contributed to the state of the connection. If they are not= included, then the "Finished" HMAC does not offer a protection a= gainst tampering. This may open the possibility of some kind of substitutio= n or replay attack.

They are included i= n the client's 0-RTT Finished, so as long as SS is not
compro= mised, you should not be able to modify them. They are not protected
<= div>against modifications if SS is compromised, whereas other messages are<= /div>
covered by the server's signature.

<= br>
The failed 0-RTT handshake scenario also has interesting consequences on th= e Record layer. We have a legitimate scenario in which received records can= not be decrypted. This should not trigger alarms. And the numbering scheme = should be robust against these missing records.

=
Yes. Resetting the sequence number as proposed by Fournet et al. and
in WIP-11 makes this easier.

-Ekr

--001a114dcf6af603870527abbed9-- From nobody Thu Dec 24 13:49:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3306E1A6EE8 for ; Thu, 24 Dec 2015 13:49:40 -0800 (PST) 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, HTML_MESSAGE=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 KWeqEZNsFXDP for ; Thu, 24 Dec 2015 13:49:38 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A31A1A6EED for ; Thu, 24 Dec 2015 13:49:38 -0800 (PST) Received: by mail-yk0-x22e.google.com with SMTP id x184so232509392yka.3 for ; Thu, 24 Dec 2015 13:49:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iwCneAgZ4HxtiowgSnaasj5rIr5BOVTrWZCG1HKxHTM=; b=BwLnk8/rirvQicWMlFUSdhXze+RlGbcVQug4vUTwU0CA1uD/w3B1SkgncCdCCmnHm+ DxTlEm5j4avBgUnJhdzYzAX1J8+vyqPZSX6BjGpRRzzCjDOGMUxZ2/iOb+Jf3yp5Ot1z LuAgrCYT3v9RXLByE/p6iK3+PqD/K3Z5zZjPFeebFCmS3acVoK0+Hm3h1xdNp+R97EE7 XCLNe+bFUl5AY0zGIrQqPRzd8biGlXhm13MZ+uf8417oPIFbKfxBl/gqTk9IqyaZWlfX KNRJZ3zBumpygbtWeBEhkMirCBC3T3W4jmHi6Dt6AFpkYVn06Sef7w226qTNsK4B0TbV 0qlw== 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=iwCneAgZ4HxtiowgSnaasj5rIr5BOVTrWZCG1HKxHTM=; b=KDNp2ZJ6NuOMCxwUcZcACD6Rm/iDqmWGaIJeuddEYcR9P8BaehckApahn5D9EyBSmw /CjB5BKyoJu5O9kqW0bBrpJcn0iWdqAScvZ6pWjLslKbm4g/KZnjYo7uV6FkdY07hPVM wuzTDj9rxkKr/WTXf5qFDjG184Of+quUGf6HXro28y5rlzyK035a9cER66hx60NElENt /DoRtU5IeG28R64psvjgLncYYrVLbYwvRDYXziWqrwWAqbBT/jtMvcIU+2T+IBFdj2Ee pdQq0erjpuA04I1EBMsvM9/hgmmmwSu4CuVcb0giTmfiKXS5vcUZ8WfV6ASg5wNCQtIy eg6Q== X-Gm-Message-State: ALoCoQl70x/xT7oeM2qDnX8wVdBLtV3yda879eNdgGbjyDsCibKgSB4s7Fe6j7bSBcCbImZsvsSE9E0kGF0HYbQr5YRblYrLgw== X-Received: by 10.129.153.3 with SMTP id q3mr32854938ywg.231.1450993777602; Thu, 24 Dec 2015 13:49:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Thu, 24 Dec 2015 13:48:58 -0800 (PST) In-Reply-To: <201512241626.41884.davemgarrett@gmail.com> References: <201512241626.41884.davemgarrett@gmail.com> From: Eric Rescorla Date: Thu, 24 Dec 2015 16:48:58 -0500 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=94eb2c0bbfaeafa57f0527abd0e5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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: Thu, 24 Dec 2015 21:49:40 -0000 --94eb2c0bbfaeafa57f0527abd0e5 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 24, 2015 at 4:26 PM, Dave Garrett wrote: > On Thursday, December 24, 2015 03:40:26 pm Christian Huitema wrote: > > On Monday, December 21, 2015 6:30 PM, Martin Thomson wrote: > > > On 22 December 2015 at 13:25, Christian Huitema > > > > wrote: > > > >> Unless I'm confused (which is possible given the time of night), > > > >> the intention, as you say, is to separate out the 0-RTT handshake > > > >> messages i.e., (cert, cert verify, finished) from the 1-RTT > computations. > > > > > > > > OK. That does not simplify implementations using running hashes... > > > > > > It does if you consider the possibility of having to drop the 0-RTT > data. > > > > That's right. In fact, it may be a good idea to add to the spec a > description of a "Failed 0-RTT handshake." If I understand correctly, the > following will happen: > > > > * Server will receive the client hello, ignore the Early Data Indication > extension, and proceed as in 1-RTT. > > * Server will indicate that by not adding an Early Data Indication to > the server hello. > > * Server will receive a series of 0-RTT messages that it cannot > decipher, and just drop the messages. > > * Client will receive server hello, and proceed as per 1-RTT. Client API > will signal that 0-RTT data was lost, application may decide to retransmit. > > * Server may send client authentication requests. Client will have to > repeat the authentication messages, even if it already sent them as 0-RTT. > > > > In that scenario, the handshake hash cannot include the 0-RTT messages, > since the server does not in fact receive them, and they do not contribute > to the state of the connection. > > > > We can of course debate whether the 0-RTT messages should also not be > included in the hash if the 0-RTT exchange was successful, the messages > were received, and they contributed to the state of the connection. If they > are not included, then the "Finished" HMAC does not offer a protection > against tampering. This may open the possibility of some kind of > substitution or replay attack. > > > > The failed 0-RTT handshake scenario also has interesting consequences on > the Record layer. We have a legitimate scenario in which received records > cannot be decrypted. This should not trigger alarms. And the numbering > scheme should be robust against these missing records. > > Do we have anything that protects against an intermediary stripping 0RTT > messages from a handshake to force a fallback? > Yes: 1. The EarlyDataIndication tells the server that some 0-RTT messages are coming. 2. The Finished in the 0-RTT flight covers the entire handshake flight, thus preventing tampering with those messages. 3. The server's Finished covers the ClientHello, thus preventing tampering with that. -Ekr Could we just make the handshake hash use the encrypted messages, > regardless of if it can decrypt them? (maybe for all messages?) > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0bbfaeafa57f0527abd0e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 24, 2015 at 4:26 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Thursday, December 24, 2015 03:40:26 pm Christian Huitema wrote:
> On Monday, December 21, 2015 6:30 PM, Martin Thomson wrote:
> > On 22 December 2015 at 13:25, Christian Huitema <huitema@microsoft.com>
> > wrote:
> > >> Unless I'm confused (which is possible given the tim= e of night),
> > >> the intention, as you say, is to separate out the 0-RTT = handshake
> > >> messages i.e., (cert, cert verify, finished) from the 1-= RTT computations.
> > >
> > > OK. That does not simplify implementations using running has= hes...
> >
> > It does if you consider the possibility of having to drop the 0-R= TT data.
>
> That's right. In fact, it may be a good idea to add to the spec a = description of a "Failed 0-RTT handshake." If I understand correc= tly, the following will happen:
>
> * Server will receive the client hello, ignore the Early Data Indicati= on extension, and proceed as in 1-RTT.
> * Server will indicate that by not adding an Early Data Indication to = the server hello.
> * Server will receive a series of 0-RTT messages that it cannot deciph= er, and just drop the messages.
> * Client will receive server hello, and proceed as per 1-RTT. Client A= PI will signal that 0-RTT data was lost, application may decide to retransm= it.
> * Server may send client authentication requests. Client will have to = repeat the authentication messages, even if it already sent them as 0-RTT.<= br> >
> In that scenario, the handshake hash cannot include the 0-RTT messages= , since the server does not in fact receive them, and they do not contribut= e to the state of the connection.
>
> We can of course debate whether the 0-RTT messages should also not be = included in the hash if the 0-RTT exchange was successful, the messages wer= e received, and they contributed to the state of the connection. If they ar= e not included, then the "Finished" HMAC does not offer a protect= ion against tampering. This may open the possibility of some kind of substi= tution or replay attack.
>
> The failed 0-RTT handshake scenario also has interesting consequences = on the Record layer. We have a legitimate scenario in which received record= s cannot be decrypted. This should not trigger alarms. And the numbering sc= heme should be robust against these missing records.

Do we have anything that protects against an intermediary stripping = 0RTT messages from a handshake to force a fallback?
Yes:
1. The EarlyDataIndication tells the server tha= t some 0-RTT messages are coming.
2. The Finished in the 0-RTT fl= ight covers the entire handshake flight, thus preventing
tamperin= g with those messages.
3. The server's Finished covers the Cl= ientHello, thus preventing tampering with that.

-E= kr


Could we just make the handshake hash use the encrypted messages, regardles= s of if it can decrypt them? (maybe for all messages?)


Dave

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

--94eb2c0bbfaeafa57f0527abd0e5-- From nobody Thu Dec 24 14:01:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15731A6F20 for ; Thu, 24 Dec 2015 14:01:52 -0800 (PST) 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 xHXFDo4LugGc for ; Thu, 24 Dec 2015 14:01:51 -0800 (PST) Received: from mail-qg0-x242.google.com (mail-qg0-x242.google.com [IPv6:2607:f8b0:400d:c04::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB6F1A6F1F for ; Thu, 24 Dec 2015 14:01:51 -0800 (PST) Received: by mail-qg0-x242.google.com with SMTP id b35so4217234qge.2 for ; Thu, 24 Dec 2015 14:01:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=fAZJwauc/Dz4LEus1IGX7jZTZyGj18U/oRyvanfkOM0=; b=fDZCadcc1cVUVFnT+TW0pKgZzkOBv+koCxJMhB77TvNofT3HNfvkm+CKuEvGN+pmCk Ey/HAJmXauYM44P8nRKluPmjtqk61kY8TOyGOdcLOfuFyWhaSTTUJ0atny37N7zNv8yN O1NIDG+T8+Ug6B60yI4Olac9KE3mG0YsCaQInIN/whcenPufSG+8F5k7w6suC3OI+iQ8 OjuMzbBWvRt51M3b+vuVhL+s0u6JZAXpR4xGixbznnmgQiXE456bWCIMS+w4xbpMJ2Zk 1Ik+5Wn3VlEWwZ6Ll+ouza1hLN7Iz6bPZm7DGH1J6iwiVeaYikmxwKEPIHUYniA25rpG MHhg== X-Received: by 10.140.168.85 with SMTP id o82mr43739431qho.8.1450994510561; Thu, 24 Dec 2015 14:01:50 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id u67sm3117391qku.1.2015.12.24.14.01.50 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 24 Dec 2015 14:01:50 -0800 (PST) From: Dave Garrett To: Eric Rescorla Date: Thu, 24 Dec 2015 17:01:48 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201512241626.41884.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201512241701.49373.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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: Thu, 24 Dec 2015 22:01:53 -0000 On Thursday, December 24, 2015 04:48:58 pm Eric Rescorla wrote: > On Thu, Dec 24, 2015 at 4:26 PM, Dave Garrett > wrote: > > Do we have anything that protects against an intermediary stripping 0RTT > > messages from a handshake to force a fallback? > > Yes: > 1. The EarlyDataIndication tells the server that some 0-RTT messages are > coming. > 2. The Finished in the 0-RTT flight covers the entire handshake flight, > thus preventing > tampering with those messages. > 3. The server's Finished covers the ClientHello, thus preventing tampering > with that. #1 & #3 are easily dealt with by injecting bogus 0-RTT messages that get rejected, at which point a 0RTT could be prevented and we won't get to #2. So, the client sends a handshake with 0RTT, an intermediary strips it and replaces it with something that fills the slot, but will get rejected, the server rejects it and falls back to 1RTT, and then the client would have to accept this. This intermediary thus has the power to force any 0RTT attempt to fall back to 1RTT. Dave From nobody Thu Dec 24 14:14:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D5E1A6F57 for ; Thu, 24 Dec 2015 14:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] 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 jV6_8EeVLKAz for ; Thu, 24 Dec 2015 14:14:57 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C261A6F51 for ; Thu, 24 Dec 2015 14:14:57 -0800 (PST) Received: by mail-yk0-x236.google.com with SMTP id x67so45226400ykd.2 for ; Thu, 24 Dec 2015 14:14:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hsvwySKQsN1S1tlcHA+tdSvEcY4xCB8nWloo9BcYsFU=; b=GiKDlbAPYo9wmrosrUDloiccCTtbkU7u4QlwzwyKGS+TD+4r94Jprq3zsikJaJv+/U niCXO/s1Zg1rUNkHFB3XlyQEMfdIgnif2Agb60QlcfYi0xpaLoHvKnsJLJLxT/tk5L7Z QuPm0Lm+0+l+wah2zIJz+0LGX/gWSBNZwJkoBkm6kYsBvwFk3DhFflSnsbNCyq0mG29I vKSve0KH7dr+CaHULqRivVnkVrTmmcpEbULbY3KN5ZhdAC3+QMeDRUfYgrdPjbd+I8ZC 0ZNcKEnwK5R/osbBSwpQMeY8ZFswIu0Aq8bFY/TeINTy83I0U0CJhOuEbrjDKkWZ4g39 oukg== 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=hsvwySKQsN1S1tlcHA+tdSvEcY4xCB8nWloo9BcYsFU=; b=jVEu/PpPXZedUnPPi1YfJcezj1tgov/ViD+C8aDNWYiM0dlH+SUBdvc5ffmuS1NLLg eEtbnXfvyk/ZOwhGSvgb6ge3xSS5NMMl1l3zGP41CKY4pjxQzn6wwf1XSqBZvxq7GcZs Xwe4MztIsjqGIxv7Lyoyp8WaLsbGWgItNrKUh/QiesO+gIzdqGUNnq79m+xgdGXs7OXf nwhg4iLQ5zdR4aHlsIDc94RxBOPL/1dB3cu059PUbKvNuRFV2XpROb3ybvoQ3j3UhSwj cuRv9bZF7OW/ndKIxaL565wGwo0uqkgXSB91HRQm7QMP3PfePImsG2hOdJzTVAn6uXEN 9URg== X-Gm-Message-State: ALoCoQme2Jr1xLyvoicRIEuZKjpiO9Nr4hgA7cJLnJEMtVn9ZvL3JRYI6q3lK+8tFaqLEleiUiu9DLb9x9cN1loXctYPi1FOVA== X-Received: by 10.13.193.4 with SMTP id c4mr34291405ywd.192.1450995296409; Thu, 24 Dec 2015 14:14:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Thu, 24 Dec 2015 14:14:17 -0800 (PST) In-Reply-To: <201512241701.49373.davemgarrett@gmail.com> References: <201512241626.41884.davemgarrett@gmail.com> <201512241701.49373.davemgarrett@gmail.com> From: Eric Rescorla Date: Thu, 24 Dec 2015 17:14:17 -0500 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a114caa9e36cf020527ac2be6 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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: Thu, 24 Dec 2015 22:14:58 -0000 --001a114caa9e36cf020527ac2be6 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 24, 2015 at 5:01 PM, Dave Garrett wrote: > On Thursday, December 24, 2015 04:48:58 pm Eric Rescorla wrote: > > On Thu, Dec 24, 2015 at 4:26 PM, Dave Garrett > > wrote: > > > Do we have anything that protects against an intermediary stripping > 0RTT > > > messages from a handshake to force a fallback? > > > > Yes: > > 1. The EarlyDataIndication tells the server that some 0-RTT messages are > > coming. > > 2. The Finished in the 0-RTT flight covers the entire handshake flight, > > thus preventing > > tampering with those messages. > > 3. The server's Finished covers the ClientHello, thus preventing > tampering > > with that. > > #1 & #3 are easily dealt with by injecting bogus 0-RTT messages that get > rejected, at which point a 0RTT could be prevented and we won't get to #2. > > So, the client sends a handshake with 0RTT, an intermediary strips it and > replaces it with something that fills the slot, but will get rejected, the > server rejects it and falls back to 1RTT, and then the client would have to > accept this. This intermediary thus has the power to force any 0RTT attempt > to fall back to 1RTT. > This doesn't sound correct. 1. The client sends a ClientHello with an EarlyDataIndication indicating configuration=C (and server key g^s) and ClientHello.key_share = x. 2. The server processes the ClientHello and determines whether 0-RTT will be accepted or rejected based purely on the ClientHello. I.e., it doesn't need to read any more messages before deciding this [0]. If it decides to accept 0-RTT then it expects the next messages to be 0-RTT handshake messages encrypted with SS = g^xs. If those messages don't decrypt properly, then it needs to fail the entire connection (fatal alert with bad_record_mac). 3. The attacker *could* modify the ClientHello to replace C with C', which would cause the server to fall back to 1-RTT, but then the server's CertificateVerify and Finished would both be incorrect, causing the handshake to fail when the client tries to process them. If you still think I'm wrong here, it would help me if you provide a ladder diagram indicating the attack you are concerned about. Thanks, -Ekr [0] Technically speaking, it should be possible to send ServerHello before even reading the remainder of the first flight. --001a114caa9e36cf020527ac2be6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 24, 2015 at 5:01 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Thursday, December 24, 2015 04:48:58 pm Eric Rescorla wrote:
> On Thu, Dec 24, 2015 at 4:26 PM, Dave Garrett <davemgarrett@gmail.com>
> wrote:
> > Do we have anything that protects against= an intermediary stripping 0RTT
> > messages from a handshake to force a fallback?
>
> Yes:
> 1. The EarlyDataIndication tells the server that some 0-RTT messages a= re
> coming.
> 2. The Finished in the 0-RTT flight covers the entire handshake flight= ,
> thus preventing
> tampering with those messages.
> 3. The server's Finished covers the ClientHello, thus preventing t= ampering
> with that.

#1 & #3 are easily dealt with by injecting bogus 0-RTT messages = that get rejected, at which point a 0RTT could be prevented and we won'= t get to #2.

So, the client sends a handshake with 0RTT, an intermediary strips it and r= eplaces it with something that fills the slot, but will get rejected, the s= erver rejects it and falls back to 1RTT, and then the client would have to = accept this. This intermediary thus has the power to force any 0RTT attempt= to fall back to 1RTT.

This doesn't= sound correct.

1. The client sends a ClientHello = with an EarlyDataIndication indicating configuration=3DC
(and ser= ver key g^s) and ClientHello.key_share =3D x.

2. T= he server processes the ClientHello and determines whether 0-RTT will be ac= cepted
or rejected based purely on the ClientHello. I.e., it does= n't need to read any more messages
before deciding this [0]. = If it decides to accept 0-RTT then it expects the next messages to
be 0-RTT handshake messages encrypted with SS =3D g^xs. If those messages= don't decrypt
properly, then it needs to fail the entire con= nection (fatal alert with bad_record_mac).=C2=A0

3= . The attacker *could* modify the ClientHello to replace C with C', whi= ch would cause
the server to fall back to 1-RTT, but then the ser= ver's CertificateVerify and Finished would
both be incorrect,= causing the handshake to fail when the client tries to process them.
=

If you still think I'm wrong here, it would help me= if you provide a ladder diagram indicating
the attack you are co= ncerned about.

Thanks,
-Ekr
[0] Technically speaking, it should be possible to send Server= Hello before even reading
the remainder of the first flight.

--001a114caa9e36cf020527ac2be6-- From nobody Thu Dec 24 14:48:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749BC1A6FAA for ; Thu, 24 Dec 2015 14:48:29 -0800 (PST) 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_12=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 4la3oUbVIE1r for ; Thu, 24 Dec 2015 14:48:28 -0800 (PST) Received: from mail-qg0-x241.google.com (mail-qg0-x241.google.com [IPv6:2607:f8b0:400d:c04::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31AD41A6FA8 for ; Thu, 24 Dec 2015 14:48:27 -0800 (PST) Received: by mail-qg0-x241.google.com with SMTP id 6so7082435qgy.3 for ; Thu, 24 Dec 2015 14:48:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=0ZZHYywcsKzzv0XNuuqJzDs+WSyv4Z2cYdpvr4Xv63A=; b=z9j0/poRGhX5/DfCl4KWbaB8eUeReUzEfGU0ObXfPufegEfRZh/iClR+XtkYStoCF5 ipwDMil4P1FC+luacutXqEFG+ZiW+XVlvtcQ/cs9oyKv2CEz1MeD59LVsfiwiqCtQM+0 u//OoCR1nF0DDtNsdwcvsP9XHBQNJhsTYgF0sFd6Bue7K3fKPgpvC9ZTV/4B6MoRai0S cqRzm2SuGHGbTlVHeQ/f3pNX4+ONpd3bX2UDxVpYWjav9qPRwtnqhq0lvgwtFsL0wpfA JG9QJRXn6l7SS4rEvuiln1Ajt9wzZyQEsZPXEnQJPe9fShG1eqtS4HRKsbcwT3CijRtl tIHQ== X-Received: by 10.140.138.69 with SMTP id 66mr54868789qhk.18.1450997307073; Thu, 24 Dec 2015 14:48:27 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id z65sm20674530qhb.22.2015.12.24.14.48.26 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 24 Dec 2015 14:48:26 -0800 (PST) From: Dave Garrett To: Eric Rescorla Date: Thu, 24 Dec 2015 17:48:25 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201512241701.49373.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Message-Id: <201512241748.25385.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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: Thu, 24 Dec 2015 22:48:29 -0000 On Thursday, December 24, 2015 05:14:17 pm Eric Rescorla wrote: > On Thu, Dec 24, 2015 at 5:01 PM, Dave Garrett > wrote: > > On Thursday, December 24, 2015 04:48:58 pm Eric Rescorla wrote: > > > On Thu, Dec 24, 2015 at 4:26 PM, Dave Garrett > > > wrote: > > So, the client sends a handshake with 0RTT, an intermediary strips it and > > replaces it with something that fills the slot, but will get rejected, the > > server rejects it and falls back to 1RTT, and then the client would have to > > accept this. This intermediary thus has the power to force any 0RTT attempt > > to fall back to 1RTT. > > This doesn't sound correct. > > 1. The client sends a ClientHello with an EarlyDataIndication indicating > configuration=C (and server key g^s) and ClientHello.key_share = x. > > 2. The server processes the ClientHello and determines whether 0-RTT will be accepted > or rejected based purely on the ClientHello. I.e., it doesn't need to read any more messages > before deciding this [0]. If it decides to accept 0-RTT then it expects the next messages to > be 0-RTT handshake messages encrypted with SS = g^xs. If those messages don't decrypt > properly, then it needs to fail the entire connection (fatal alert with bad_record_mac). This last bit stops this, yes. I would prefer the spec say this very explicitly, as right now it doesn't and all I see is a line saying: "If any of these checks fail, the server MUST NOT respond with the extension and must discard all the remaining first flight data (thus falling back to 1-RTT)." The current text doesn't explicitly say how to handle 0-RTT data that it thinks it should be able to decrypt but can't. After rereading things a bit I think you're correct in that the correct course of action the spec currently expects is to abort, however implementers frequently err on the side of working partially vs not at all when given any wiggle room. A clear hard "MUST abort" on failed decrypt of 0RTT data would deal with this and avoid any other possible misunderstanding. Either do or do not; no try. > 3. The attacker *could* modify the ClientHello to replace C with C', which would cause > the server to fall back to 1-RTT, but then the server's CertificateVerify and Finished would > both be incorrect, causing the handshake to fail when the client tries to process them. > > If you still think I'm wrong here, it would help me if you provide a ladder diagram indicating > the attack you are concerned about. > > Thanks, > -Ekr > > [0] Technically speaking, it should be possible to send ServerHello before > even reading the remainder of the first flight. Also, I found a typo in the early data section. The config ID was referred to by two names. PR filed. ;) Dave From nobody Thu Dec 24 17:09:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840C51A8825 for ; Thu, 24 Dec 2015 17:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] 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 mBPnQJFDba5s for ; Thu, 24 Dec 2015 17:09:05 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EBD01A87F2 for ; Thu, 24 Dec 2015 17:09:05 -0800 (PST) Received: by mail-yk0-x231.google.com with SMTP id k129so26523659yke.0 for ; Thu, 24 Dec 2015 17:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=V9yRy25EftyvaYwc/8T+2IBPf1MYtjMkf7gI+KcH2JY=; b=biOcHVkkROIj+5/ooNuetnKTx6stCQVIFKbmesu/K0biGwwjz+/WEyDOrr8cANqZue TUZKFr1pwZpSz4/BBYUIhHGZ2rkEgRUYyJzsQ+cwqSSqjSI8tI7271lG5m2Jfgdntipl 9q60xerETbl993GtOOO4A8RgI5x5fowPvCUQLDLhxGsDTmPjlDOJxhrAgRz0YPOl3FbC TDgebFRmLDC2ahn0rIfEg8yAT9YILPWSYqwzaPPHtw0EHDHzaCby2pYYC/adpAihK3TT akH7iZcx2pMDSREAoceHko1B/kv9qxfG8p2V9hl4WpEr1mp2gU8BQ43D+3L1tcUub2K5 DGpw== 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=V9yRy25EftyvaYwc/8T+2IBPf1MYtjMkf7gI+KcH2JY=; b=gKocg4DrKHpcMY5ZCTo6MmBoNqX9WdG3g+9eYZmL+1DpVaWJgZT/2dKWiW8InMCKIu KGs+nAFIe9I2uPKF255FGBcwbE0QodY/fSVR1G0dWioATZqygAYR+rsGBrriYd2gKlMy Zefbor3zDk8jvasl6f6PEUMwNM9m0uT/45pkivTU4+HUSUpe31xjDbxhoSeZrSaP8ide tuEsiCfo/zuJLuw8J8AU78yjPjSJ3UcnG3sZ5lfOYVEVk+qlUPbBTCZ23U6CIDS7mHfc qMywfgmTM5D0VcgIGIGLUB4REz9rmDQ80XP53RMErfwdDDmAyTufKvSq2MlvuqmV/3Ac VciA== X-Gm-Message-State: ALoCoQlZNOq+ptG75ocekoETM7E7LIL04ox0CV02T34iVC2Zb2KFW3KRH0YM+1LXiNDb/BGxD9YahlYosK63av3DCFUFWxRf+A== X-Received: by 10.13.193.4 with SMTP id c4mr34679013ywd.192.1451005744890; Thu, 24 Dec 2015 17:09:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Thu, 24 Dec 2015 17:08:25 -0800 (PST) In-Reply-To: <201512241748.25385.davemgarrett@gmail.com> References: <201512241701.49373.davemgarrett@gmail.com> <201512241748.25385.davemgarrett@gmail.com> From: Eric Rescorla Date: Thu, 24 Dec 2015 20:08:25 -0500 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a114caa9efdf7550527ae99b6 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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, 25 Dec 2015 01:09:07 -0000 --001a114caa9efdf7550527ae99b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett wrote: > On Thursday, December 24, 2015 05:14:17 pm Eric Rescorla wrote: > > On Thu, Dec 24, 2015 at 5:01 PM, Dave Garrett > > wrote: > > > On Thursday, December 24, 2015 04:48:58 pm Eric Rescorla wrote: > > > > On Thu, Dec 24, 2015 at 4:26 PM, Dave Garrett < > davemgarrett@gmail.com> > > > > wrote: > > > So, the client sends a handshake with 0RTT, an intermediary strips it > and > > > replaces it with something that fills the slot, but will get rejected= , > the > > > server rejects it and falls back to 1RTT, and then the client would > have to > > > accept this. This intermediary thus has the power to force any 0RTT > attempt > > > to fall back to 1RTT. > > > > This doesn't sound correct. > > > > 1. The client sends a ClientHello with an EarlyDataIndication indicatin= g > > configuration=3DC (and server key g^s) and ClientHello.key_share =3D x. > > > > 2. The server processes the ClientHello and determines whether 0-RTT > will be accepted > > or rejected based purely on the ClientHello. I.e., it doesn't need to > read any more messages > > before deciding this [0]. If it decides to accept 0-RTT then it expects > the next messages to > > be 0-RTT handshake messages encrypted with SS =3D g^xs. If those messag= es > don't decrypt > > properly, then it needs to fail the entire connection (fatal alert with > bad_record_mac). > > This last bit stops this, yes. I would prefer the spec say this very > explicitly, as right now it doesn't and all I see is a line saying: > "If any of these checks fail, the server MUST NOT respond with the > extension and must discard all the remaining first flight data (thus > falling back to 1-RTT)." Well, this is a general requirement any time the record MAC is bad: See http://tlswg.github.io/tls13-spec/#rfc.section.5.2.2 "If the decryption fails, a fatal =E2=80=9Cbad_record_mac=E2=80=9D alert MU= ST be generated." > The current text doesn't explicitly say how to handle 0-RTT data that it > thinks it should be able to decrypt but can't. After rereading things a b= it > I think you're correct in that the correct course of action the spec > currently expects is to abort, however implementers frequently err on the > side of working partially vs not at all when given any wiggle room. A cle= ar > hard "MUST abort" on failed decrypt of 0RTT data would deal with this and > avoid any other possible misunderstanding. Either do or do not; no try. > If you have suggested text, I'd be happy to see a PR. > 3. The attacker *could* modify the ClientHello to replace C with C', > which would cause > > the server to fall back to 1-RTT, but then the server's > CertificateVerify and Finished would > > both be incorrect, causing the handshake to fail when the client tries > to process them. > > > > If you still think I'm wrong here, it would help me if you provide a > ladder diagram indicating > > the attack you are concerned about. > > > > Thanks, > > -Ekr > > > > [0] Technically speaking, it should be possible to send ServerHello > before > > even reading the remainder of the first flight. > > Also, I found a typo in the early data section. The config ID was referre= d > to by two names. PR filed. ;) Merged. -Ekr > > Dave > --001a114caa9efdf7550527ae99b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Thursday= , December 24, 2015 05:14:17 pm Eric Rescorla wrote:
> On Thu, Dec 24, 2015 at 5:01 PM, Dave Garrett <davemgarrett@gmail.com>
> wrote:
> > On Thursday, December 24, 2015 04:48:58 pm Eric Rescorla wrote: > > > On Thu, Dec 24, 2015 at 4:26 PM, Dave Garrett <davemgarrett@gmail.com>
> > > wrote:
> > So, the client sends a handshake with 0RT= T, an intermediary strips it and
> > replaces it with something that fills the slot, but will get reje= cted, the
> > server rejects it and falls back to 1RTT, and then the client wou= ld have to
> > accept this. This intermediary thus has the power to force any 0R= TT attempt
> > to fall back to 1RTT.
>
> This doesn't sound correct.
>
> 1. The client sends a ClientHello with an EarlyDataIndication indicati= ng
> configuration=3DC (and server key g^s) and ClientHello.key_share =3D x= .
>
> 2. The server processes the ClientHello and determines whether 0-RTT w= ill=C2=A0 be accepted
> or rejected based purely on the ClientHello. I.e., it doesn't need= to read any more messages
> before deciding this [0]. If it decides to accept 0-RTT then it expect= s the next messages to
> be 0-RTT handshake messages encrypted with SS =3D g^xs. If those messa= ges don't decrypt
> properly, then it needs to fail the entire connection (fatal alert wit= h bad_record_mac).

This last bit stops this, yes. I would prefer the spec say this very= explicitly, as right now it doesn't and all I see is a line saying: "If any of these checks fail, the server MUST NOT respond with the ext= ension and must discard all the remaining first flight data (thus falling b= ack to 1-RTT)."

Well, this is a genera= l requirement any time the record MAC is bad:
"If the decryption fails, a = fatal =E2=80=9Cbad_record_mac=E2=80=9D alert MUST be generated."
=

=C2=A0
The current text doesn't explicitly say how to handle 0-RTT data that i= t thinks it should be able to decrypt but can't. After rereading things= a bit I think you're correct in that the correct course of action the = spec currently expects is to abort, however implementers frequently err on = the side of working partially vs not at all when given any wiggle room. A c= lear hard "MUST abort" on failed decrypt of 0RTT data would deal = with this and avoid any other possible misunderstanding. Either do or do no= t; no try.

If you have suggested text, = I'd be happy to see a PR.


> 3. The attacker *could* modify the ClientHello to replace C with C'= ;, which would cause
> the server to fall back to 1-RTT, but then the server's Certificat= eVerify and Finished would
> both be incorrect, causing the handshake to fail when the client tries= to process them.
>
> If you still think I'm wrong here, it would help me if you provide= a ladder diagram indicating
> the attack you are concerned about.
>
> Thanks,
> -Ekr
>
> [0] Technically speaking, it should be possible to send ServerHello be= fore
> even reading=C2=A0 the remainder of the first flight.

Also, I found a typo in the early data section. The config ID was re= ferred to by two names. PR filed. ;)

Merged= .

-Ekr
=C2=A0

Dave

--001a114caa9efdf7550527ae99b6-- From nobody Fri Dec 25 00:04:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B381A8989 for ; Fri, 25 Dec 2015 00:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 JUQn6mYEiLMm for ; Fri, 25 Dec 2015 00:04:21 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 436801A8988 for ; Fri, 25 Dec 2015 00:04:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 1E830237B; Fri, 25 Dec 2015 10:04:19 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 4lS2pIH1JaF2; Fri, 25 Dec 2015 10:04:18 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id B540D138; Fri, 25 Dec 2015 10:04:18 +0200 (EET) Date: Fri, 25 Dec 2015 10:04:18 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20151225080417.GA2800@LK-Perkele-V2.elisa-laajakaista.fi> References: <201512241701.49373.davemgarrett@gmail.com> <201512241748.25385.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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, 25 Dec 2015 08:04:23 -0000 On Thu, Dec 24, 2015 at 08:08:25PM -0500, Eric Rescorla wrote: > On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett > wrote: > > > > This last bit stops this, yes. I would prefer the spec say this very > > explicitly, as right now it doesn't and all I see is a line saying: > > "If any of these checks fail, the server MUST NOT respond with the > > extension and must discard all the remaining first flight data (thus > > falling back to 1-RTT)." > > Well, this is a general requirement any time the record MAC is bad: > See http://tlswg.github.io/tls13-spec/#rfc.section.5.2.2 > "If the decryption fails, a fatal “bad_record_mac†alert MUST be generated." > > > The current text doesn't explicitly say how to handle 0-RTT data that it > > thinks it should be able to decrypt but can't. After rereading things a bit > > I think you're correct in that the correct course of action the spec > > currently expects is to abort, however implementers frequently err on the > > side of working partially vs not at all when given any wiggle room. A clear > > hard "MUST abort" on failed decrypt of 0RTT data would deal with this and > > avoid any other possible misunderstanding. Either do or do not; no try. > > > > If you have suggested text, I'd be happy to see a PR. Except that when server is doing 1RTT fallback and skipping 0-RTT data, then records that get deprotect failure (is that the proper term?) are ignored instead of generating bad_record_mac like "normal" deprotect failure would. Then there's also the case where server is skipping 0-RTT data for retry (there one can recognize end of data from content-type 23 changing back to 22). Then one has to ensure that configuration_id's are never reused: If client and server disagree about server-valid configuration, the result can easily be hard failure (instead of fallback). One server-side trick to ensure non-reuse would be to hash the server certificate and the configuration messages (with configuration_id being zeroes of approriate length) using e.g. SHA-256 and then use the resulting hash as configuration_id. -Ilari From nobody Fri Dec 25 06:11:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152481A014C for ; Fri, 25 Dec 2015 06:11:16 -0800 (PST) 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, HTML_MESSAGE=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 0sKM56dEDL1L for ; Fri, 25 Dec 2015 06:11:14 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A081A0115 for ; Fri, 25 Dec 2015 06:11:13 -0800 (PST) Received: by mail-yk0-x229.google.com with SMTP id x67so56348216ykd.2 for ; Fri, 25 Dec 2015 06:11:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=c2hNEOFSEqALCrErbhw64a2wzkGf+/OAn88WSHm8sdY=; b=pwVdPZUBw3MPWIyd/E5SUfauE+JfxXUx9u7KJFYm1uEK/l6hRYsIRLPDffBpKJthqx 5+pkgvfunBqAnHBf8++QSX4ghIyOYb1PQeaBEnJOHXqWEei8ghLJUYYDJza3qFAlGf/L jmAgXstfVFtfVdyz6sq5gjQDaV1mWZajeI1R0bl0IDKtyThQjFuyHuk18Ygg+oIMLoQo 59HX2jTd+7SHJI1OeuUaCGeo9s5Jos2xGyk9jv0InJKnvg3EbbLuHhQjp0sv31hR+BrD XOdr56QmSKI4VtaMQlWPLDQdS/vfAcicEHqJdiws+Othu15wmBSyJQIRwY5jfB82bfmV L1Xw== 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=c2hNEOFSEqALCrErbhw64a2wzkGf+/OAn88WSHm8sdY=; b=P5ygPJDuTinKDPmloUgbXc05ITBdza/pW4xWrH/cYN5RKDejydgLa3oTy3TCg+e8VJ GQZpVkHQyFCJtQ6PnHvsPdK2o/JdCHLi25HtExTpGe+7xVyrnhup3TJ1rdxBgljH+Jo4 P4zMhaU4jE/pNoNbtISk+3aN58igrWyifRsIW4qorPXadA74AaHVwz2xYXEvYMFv/wv4 QmdoaJ9l8LNkthRWoHVAxOF7kBvUuAPIkpEygjX+Lzz4j5Ge5Y0FJNP889KrUXEcH3eA nyjhX52CpXCHsJmBxSyd99zgCiL2QYvlgy0GbReGC+9+3deCvnh5//c+6pSxyN89vMpU xkQg== X-Gm-Message-State: ALoCoQk01rg54l3K3QkZLUQ4FraDRMUyvfz5zZxPxjHEVfqVNZ/wAXzu3x527yWmfutQbZdH7ge4Gc9GxbwzbACn9zYAH41OCA== X-Received: by 10.129.148.3 with SMTP id l3mr31258213ywg.155.1451052673230; Fri, 25 Dec 2015 06:11:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Fri, 25 Dec 2015 06:10:33 -0800 (PST) In-Reply-To: <20151225080417.GA2800@LK-Perkele-V2.elisa-laajakaista.fi> References: <201512241701.49373.davemgarrett@gmail.com> <201512241748.25385.davemgarrett@gmail.com> <20151225080417.GA2800@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Fri, 25 Dec 2015 09:10:33 -0500 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c07c8bc239ae70527b98725 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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, 25 Dec 2015 14:11:16 -0000 --94eb2c07c8bc239ae70527b98725 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 25, 2015 at 3:04 AM, Ilari Liusvaara wrote: > On Thu, Dec 24, 2015 at 08:08:25PM -0500, Eric Rescorla wrote: > > On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett > > wrote: > > > > > > This last bit stops this, yes. I would prefer the spec say this very > > > explicitly, as right now it doesn't and all I see is a line saying: > > > "If any of these checks fail, the server MUST NOT respond with the > > > extension and must discard all the remaining first flight data (thus > > > falling back to 1-RTT)." > > > > Well, this is a general requirement any time the record MAC is bad: > > See http://tlswg.github.io/tls13-spec/#rfc.section.5.2.2 > > "If the decryption fails, a fatal =E2=80=9Cbad_record_mac=E2=80=9D aler= t MUST be > generated." > > > > > The current text doesn't explicitly say how to handle 0-RTT data that > it > > > thinks it should be able to decrypt but can't. After rereading things > a bit > > > I think you're correct in that the correct course of action the spec > > > currently expects is to abort, however implementers frequently err on > the > > > side of working partially vs not at all when given any wiggle room. A > clear > > > hard "MUST abort" on failed decrypt of 0RTT data would deal with this > and > > > avoid any other possible misunderstanding. Either do or do not; no tr= y. > > > > > > > If you have suggested text, I'd be happy to see a PR. > > Except that when server is doing 1RTT fallback and skipping 0-RTT data, > then records that get deprotect failure (is that the proper term?) are > ignored instead of generating bad_record_mac like "normal" deprotect > failure would. > > Then there's also the case where server is skipping 0-RTT data for retry > (there one can recognize end of data from content-type 23 changing back > to 22). > Correct. These need to be special cased. And of course with DTLS you just drop such packets rather than terminating the connectin. However, it's worth nothing that even if the first-flight handshake data weren't encrypted, it would still not be possible to create confusion here because the server would still be waiting for the 0-RTT Finished message prior to being willing to accept application data from the client. Then one has to ensure that configuration_id's are never reused: If > client and server disagree about server-valid configuration, the result > can easily be hard failure (instead of fallback). > Yes, agreed. I had always assumed that configuration ids were unique. One server-side trick to ensure non-reuse would be to hash the server > certificate and the configuration messages (with configuration_id being > zeroes of approriate length) using e.g. SHA-256 and then use the resultin= g > hash as configuration_id. > -Ekr > > > > > -Ilari > --94eb2c07c8bc239ae70527b98725 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 25, 2015 at 3:04 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Thu, Dec 24, 2015 at 08:08:25PM -0500, Eric Rescorla wrote: > On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett <davemgarrett@gmail.com>
> wrote:
> >
> > This last bit stops this, yes. I would pr= efer the spec say this very
> > explicitly, as right now it doesn't and all I see is a line s= aying:
> > "If any of these checks fail, the server MUST NOT respond wi= th the
> > extension and must discard all the remaining first flight data (t= hus
> > falling back to 1-RTT)."
>
> Well, this is a general requirement any time the record MAC is bad: > See http://tlswg.github.io/tls13-spec/#rfc.= section.5.2.2
> "If the decryption fails, a fatal =E2=80=9Cbad_record_mac=E2=80= =9D alert MUST be generated."
>
> > The current text doesn't explicitly say how to handle 0-RTT d= ata that it
> > thinks it should be able to decrypt but can't. After rereadin= g things a bit
> > I think you're correct in that the correct course of action t= he spec
> > currently expects is to abort, however implementers frequently er= r on the
> > side of working partially vs not at all when given any wiggle roo= m. A clear
> > hard "MUST abort" on failed decrypt of 0RTT data would = deal with this and
> > avoid any other possible misunderstanding. Either do or do not; n= o try.
> >
>
> If you have suggested text, I'd be happy to see a PR.

Except that when server is doing 1RTT fallback and skipping 0-RTT da= ta,
then records that get deprotect failure (is that the proper term?) are
ignored instead of generating bad_record_mac like "normal" deprot= ect
failure would.

Then there's also the case where server is skipping 0-RTT data for retr= y
(there one can recognize end of data from content-type 23 changing back
to 22).

Correct. These need to be speci= al cased. And of course with DTLS you
just drop such packets rath= er than terminating the connectin.

However, it'= ;s worth nothing that even if the first-flight handshake data
wer= en't encrypted, it would still not be possible to create confusion
here because the server would still be waiting for the 0-RTT Finished=
message prior to being willing to accept application data from t= he
client.




Then one has to ensure that configuration_id's are never reused: If
client and server disagree about server-valid configuration, the result
can easily be hard failure (instead of fallback).

=
Yes, agreed. I had always assumed that configuration ids were un= ique.


One server-side trick to ensure non-reuse would be to hash the server
certificate and the configuration messages (with configuration_id being
zeroes of approriate length) using e.g. SHA-256 and then use the resulting<= br> hash as configuration_id.


-Ekr
=C2=A0




-Ilari

--94eb2c07c8bc239ae70527b98725-- From nobody Fri Dec 25 08:47:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3034F1A8AD7 for ; Fri, 25 Dec 2015 08:47:12 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 foqP4wz_HLjQ for ; Fri, 25 Dec 2015 08:47:10 -0800 (PST) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B521A8ACB for ; Fri, 25 Dec 2015 08:47:10 -0800 (PST) Received: by mail-qg0-x234.google.com with SMTP id o11so113076124qge.2 for ; Fri, 25 Dec 2015 08:47:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=l89WyglNcrHEQmjwxvcQy6oJfjNhho30kty+8C6WfTw=; b=r2MiBt9OjLn8fHJpYb0A3Nv/xkF6MyNZrvhST24h4PBvASbYpfxLrQZQIYhG0Jk4yH H6naTz5fElDVKxkC8Ti7v7edoRUqXFr9bIcMnozQdJggo8uCyrRJxSRA/e3FfjiiQ7n5 zLK0LmfO2K5hoTh+qm/ArGFZB0QhN8/InE8aEF6Kaa8vbh4Wu/nv7ScJzTyrrYPD0uNL rtL6+zZ5k7gubRxaE6zpqiJUXlKEEHfXKS3I2ZKqGyi/5fZSGEHeHq5fNmJaETJnlYES C9Pz8KfPEKKY4wMQoGH8RFGrHNJO+Ou+E8qO4jL1m7JYJOjsBq4elVp9Cvt3EOr0+5RZ TSOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=l89WyglNcrHEQmjwxvcQy6oJfjNhho30kty+8C6WfTw=; b=MygNoZ6JsHQq04Faqb/B+PeOKUQAIGJxYs2x0QziIbu1OVmfN0Igr3B7EOSPLntVgZ 69xlkFtMoT8mXNs4fjDxVgFoPv9mZjQt2UwEM2cqvF6a5G/PpXzDxw18dRX9SKWxbtKh esqtPELEv7wcpvm55fTo7sjGh1gj1edp729vMc7gUmbrqp2STFdzbhAUBx4+5vvnnKl0 GJd2CFvp9AUQfhUoQK+wbxh6CXJEhQ3G3IOSCAHw/9Gzt533NGhXjZx+jdcvp50Y3KSs JLI+1xV8yfadO0B7bXAxRaDLXS4715y1KrTjGM6KWja/bc1VfXpBmlgdCS11b8t2/2Iu UO2w== X-Gm-Message-State: ALoCoQkIPkGKuYBidQOk+4wecPlZV954882DJ03NulbnnwvbBV4Ya3bHkWy8nYzPlIyPBu5KIil8yuoUzK+Baw/kqEweLYoVsA== X-Received: by 10.140.92.84 with SMTP id a78mr42953903qge.10.1451062029441; Fri, 25 Dec 2015 08:47:09 -0800 (PST) Received: from ?IPv6:2601:148:c000:1bb4:b55d:8057:c951:6bd8? ([2601:148:c000:1bb4:b55d:8057:c951:6bd8]) by smtp.gmail.com with ESMTPSA id l107sm6860222qge.22.2015.12.25.08.47.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Dec 2015 08:47:08 -0800 (PST) To: tls@ietf.org References: From: Michael StJohns Message-ID: <567D7310.7080000@nthpermutation.com> Date: Fri, 25 Dec 2015 11:47:12 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] A small detail in HMAC key generation for Finished message X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Dec 2015 16:47:12 -0000 On 12/23/2015 8:04 PM, Christian Huitema wrote: > On Wednesday, December 23, 2015 3:05 PM, Eric Rescorla wrote: >>> I wonder what the zero length string actually means. Is it a null-terminated string >>> that would encode in binary as a one octet byte string of value 0, or an empty >>> string that would encode in binary as a zero length string? >> I see what you mean about the ambiguity here. What I meant was 0 bytes >> (i.e., no trailing '\0'). > OK, makes sense. > >>> There is one example of encoding a string in section 4.8.1, and the binary representation >>> shows the encoding of the final null byte. Is that a common assumption? >> No. >> >>> Similarly, in the HKDF-Expand-Label, do we assume a final null byte for the "label"? >> No. I wonder if we should instead add the '\0' explicitly in the 4.8.1 for maximal clarity. > Either that, or just remove the trailing 00 from the binary description. Or even better. Express the label as a specific sequence of octets as the normative form for each and every label. That then avoids questions of the form "C String"? "Ascii"?, "Wide characters"?, etc. Mike > > -- Christian Huitema > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sat Dec 26 23:08:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C971B2AF2 for ; Sat, 26 Dec 2015 23:08:15 -0800 (PST) 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 DLrA8J5QRn83 for ; Sat, 26 Dec 2015 23:08:14 -0800 (PST) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6909E1B2AF1 for ; Sat, 26 Dec 2015 23:08:14 -0800 (PST) Received: by mail-qg0-x232.google.com with SMTP id e32so38952035qgf.3 for ; Sat, 26 Dec 2015 23:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=UTZzVvf5A+P9zWg959O1egKGX+xDiiu4YDyb7o8aMyE=; b=hsiyuoGBx1fVWSz/S5W+G14wqnOczf9V8V+Em59FOehwn5DFtPkdcV10UkBdVOabRC su2SZgiHkYUZZwO9zYR8wRCIIS/SpOdTexwCGJ9b9caMDl8nKx31K37S1rtabqD5Fg8e bqCty6qA4kPTClr6DHn6riyuyEHRb38lQQFdiDolTV+vFWVwFykg5FbVDPjmxBWQ9xTz Sx41o2yA/5dOmY2iFPj7ZNFOYTfrqCqtaJ6OiUMt8Yrh7+chZvpt+a/8F6JYG9woyJhl 0nhZKxncnlaU5G5XjlnwkRwNhQGSoc7nZCVb2KtTCpGBRybDoTPslx5BGRoI+zLh6jsr CxLQ== X-Received: by 10.140.224.207 with SMTP id u198mr63957006qhb.67.1451200093593; Sat, 26 Dec 2015 23:08:13 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id 93sm20503913qgx.16.2015.12.26.23.08.12 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 26 Dec 2015 23:08:12 -0800 (PST) From: Dave Garrett To: Eric Rescorla Date: Sun, 27 Dec 2015 02:08:10 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201512241748.25385.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201512270208.11253.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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: Sun, 27 Dec 2015 07:08:16 -0000 On Thursday, December 24, 2015 08:08:25 pm Eric Rescorla wrote: > Well, this is a general requirement any time the record MAC is bad: > See http://tlswg.github.io/tls13-spec/#rfc.section.5.2.2 > "If the decryption fails, a fatal =E2=80=9Cbad_record_mac=E2=80=9D alert = MUST be generated." >=20 > On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett > wrote: > > The current text doesn't explicitly say how to handle 0-RTT data that it > > thinks it should be able to decrypt but can't. After rereading things a= bit > > I think you're correct in that the correct course of action the spec > > currently expects is to abort, however implementers frequently err on t= he > > side of working partially vs not at all when given any wiggle room. A c= lear > > hard "MUST abort" on failed decrypt of 0RTT data would deal with this a= nd > > avoid any other possible misunderstanding. Either do or do not; no try. >=20 > If you have suggested text, I'd be happy to see a PR. Ok, I filed PR 393 with a couple sentences to clarify that 0-RTT records ar= en't allowed special treatment and errors on handling MUST NOT result in a = 1-RTT fall back. Dave From nobody Sun Dec 27 20:55:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16DE1A88A9 for ; Sun, 27 Dec 2015 20:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_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 WRxGh1Oh3Y43 for ; Sun, 27 Dec 2015 20:55:20 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0139.outbound.protection.outlook.com [65.55.169.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E76751A88A5 for ; Sun, 27 Dec 2015 20:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JFZ+xibaGErPHqQUprUzp3LYJaXLA1ehTvg8vWcBUE4=; b=LqxzHvIN0R4hSmJOJ2NyDGwofjKOWDVKjrh2rp5439nwCAgGCDZhKu0yCDlzBfwpo1/QZ0+KdAOoxRSaVO0spHou+MR06leL2l0syEsji1SdMzyhpuYCo93OcNlcwFem21gcucx2IlCThmyU3O66p0zLpAkrbSmA0fKBVFWzxdY= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0656.namprd03.prod.outlook.com (10.160.96.18) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 28 Dec 2015 04:55:17 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0361.006; Mon, 28 Dec 2015 04:55:17 +0000 From: Christian Huitema To: Dave Garrett , Eric Rescorla Thread-Topic: [TLS] What does it mean to not include 0-RTT message in the handshake hash? Thread-Index: AdE8WUzTusUbdu5EQyy4pojDDNAspQAA40EAAACQIQAAAGOBgACJ8x0AAAJUsIAAAMc6AAAAcr0AAABvnYAAATEtgAAE47KAAHElnwAALTC/YA== Date: Mon, 28 Dec 2015 04:55:16 +0000 Message-ID: References: <201512241748.25385.davemgarrett@gmail.com> <201512270208.11253.davemgarrett@gmail.com> In-Reply-To: <201512270208.11253.davemgarrett@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [72.235.151.78] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0656; 5:5K/NXCYQ+1GO6gbmxupqSdElsWLaVAzjV9H+x0xTY6jwthfm4vv+VyigMDb+ibUALGl2oURgCuM3V2rWyFOTyQTkpsdpJhbwway/Lb3nRGjz5hoRvOxOIWeNW7ZWhck2pLYPltkEq8g4T7bQDTKZqQ==; 24:YMmFWCnFsgPEW7GUh/r4Hg39cr/eW+fRCkSS8kks/lENNfK0/zu/a2e5NmyMWAtlodfJqJkjEeMhF/7X1Y3/+tZxtHPLZJRYpuW0FGg7lQ8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0656; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:DM2PR0301MB0656; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656; x-forefront-prvs: 08041D247D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(199003)(189002)(5003600100002)(105586002)(10090500001)(54356999)(86362001)(5001960100002)(5001770100001)(93886004)(92566002)(5004730100002)(5008740100001)(97736004)(5002640100001)(586003)(189998001)(99286002)(81156007)(15975445007)(66066001)(11100500001)(102836003)(6116002)(3846002)(77096005)(1096002)(1220700001)(106356001)(76176999)(8990500004)(74316001)(2950100001)(5005710100001)(122556002)(10290500002)(33656002)(101416001)(87936001)(2900100001)(10400500002)(86612001)(19580395003)(76576001)(19580405001)(40100003)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0656; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Dec 2015 04:55:16.7159 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0656 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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: Mon, 28 Dec 2015 04:55:24 -0000 T24gU2F0dXJkYXksIERlY2VtYmVyIDI2LCAyMDE1IDk6MDggUE0sIERhdmUgR2FycmV0dCB3cm90 ZToNCj4gT24gVGh1cnNkYXksIERlY2VtYmVyIDI0LCAyMDE1IDA4OjA4OjI1IHBtIEVyaWMgUmVz Y29ybGEgd3JvdGU6DQo+ID4gV2VsbCwgdGhpcyBpcyBhIGdlbmVyYWwgcmVxdWlyZW1lbnQgYW55 IHRpbWUgdGhlIHJlY29yZCBNQUMgaXMgYmFkOg0KPiA+IFNlZQ0KPiBodHRwczovL25hMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmdGxzd2cuZ2l0 aA0KPiB1Yi5pbyUyZnRsczEzLQ0KPiBzcGVjJTJmJTIzcmZjLnNlY3Rpb24uNS4yLjImZGF0YT0w MSU3YzAxJTdjaHVpdGVtYSU0MG1pY3Jvc29mdC5jb20lNw0KPiBjNTdjODQwNGExZjJmNDFhMTdm OGEwOGQzMGU4YzgyNDMlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0DQo+IDclN2Mx JnNkYXRhPW5UZGhVMWNDNnlhWWZLdnBJRzRKUjF2aFRnczgyZ0ZZZ1ZMSmJQWXNrWFElM2QNCj4g PiAiSWYgdGhlIGRlY3J5cHRpb24gZmFpbHMsIGEgZmF0YWwg4oCcYmFkX3JlY29yZF9tYWPigJ0g YWxlcnQgTVVTVCBiZSBnZW5lcmF0ZWQuIg0KPiA+DQo+ID4gT24gVGh1LCBEZWMgMjQsIDIwMTUg YXQgNTo0OCBQTSwgRGF2ZSBHYXJyZXR0IDxkYXZlbWdhcnJldHRAZ21haWwuY29tPg0KPiA+IHdy b3RlOg0KPiA+ID4gVGhlIGN1cnJlbnQgdGV4dCBkb2Vzbid0IGV4cGxpY2l0bHkgc2F5IGhvdyB0 byBoYW5kbGUgMC1SVFQgZGF0YSB0aGF0IGl0DQo+ID4gPiB0aGlua3MgaXQgc2hvdWxkIGJlIGFi bGUgdG8gZGVjcnlwdCBidXQgY2FuJ3QuIEFmdGVyIHJlcmVhZGluZyB0aGluZ3MgYSBiaXQNCj4g PiA+IEkgdGhpbmsgeW91J3JlIGNvcnJlY3QgaW4gdGhhdCB0aGUgY29ycmVjdCBjb3Vyc2Ugb2Yg YWN0aW9uIHRoZSBzcGVjDQo+ID4gPiBjdXJyZW50bHkgZXhwZWN0cyBpcyB0byBhYm9ydCwgaG93 ZXZlciBpbXBsZW1lbnRlcnMgZnJlcXVlbnRseSBlcnIgb24gdGhlDQo+ID4gPiBzaWRlIG9mIHdv cmtpbmcgcGFydGlhbGx5IHZzIG5vdCBhdCBhbGwgd2hlbiBnaXZlbiBhbnkgd2lnZ2xlIHJvb20u IEEgY2xlYXINCj4gPiA+IGhhcmQgIk1VU1QgYWJvcnQiIG9uIGZhaWxlZCBkZWNyeXB0IG9mIDBS VFQgZGF0YSB3b3VsZCBkZWFsIHdpdGggdGhpcyBhbmQNCj4gPiA+IGF2b2lkIGFueSBvdGhlciBw b3NzaWJsZSBtaXN1bmRlcnN0YW5kaW5nLiBFaXRoZXIgZG8gb3IgZG8gbm90OyBubyB0cnkuDQo+ ID4NCj4gPiBJZiB5b3UgaGF2ZSBzdWdnZXN0ZWQgdGV4dCwgSSdkIGJlIGhhcHB5IHRvIHNlZSBh IFBSLg0KPiANCj4gT2ssIEkgZmlsZWQgUFIgMzkzIHdpdGggYSBjb3VwbGUgc2VudGVuY2VzIHRv IGNsYXJpZnkgdGhhdCAwLVJUVCByZWNvcmRzIGFyZW4ndA0KPiBhbGxvd2VkIHNwZWNpYWwgdHJl YXRtZW50IGFuZCBlcnJvcnMgb24gaGFuZGxpbmcgTVVTVCBOT1QgcmVzdWx0IGluIGEgMS1SVFQN Cj4gZmFsbCBiYWNrLg0KDQpJc24ndCB0aGF0IGEgcGFydCB3aGVyZSBUTFMgYW5kIERUTFMgd2ls bCBkaWZmZXIgYSBsb3Q/DQoNCkZvciBEVExTLCB3ZSBoYXZlIHRvIGNvbnNpZGVyIHRoZSBwYWNr ZXQgaW5qZWN0aW9uIHRocmVhdC4gSXQgaXMgZmFpcmx5IGVhc3kgdG8gc2VuZCBzb21lIHJhbmRv bSBieXRlcyB3aXRoIGEgZmFrZSBzb3VyY2UgdG8gYSBVRFAgZGVzdGluYXRpb24uIFN1Y2ggYXR0 YWNrcyBzaG91bGQgbm90IGNhdXNlIHRoZSBEVExTIGFzc29jaWF0aW9uIHRvIGZhaWwhIFRoZSBu b3JtYWwgYmVoYXZpb3Igb3VnaHQgdG8gYmUgdG8ganVzdCBpZ25vcmUgVURQIHBhY2tldHMgdGhh dCBmYWlsIHRvIGRlY3J5cHQuIFRoaXMgd291bGQgY2F1c2UgMC1SVFQgcmVqZWN0cyB0byBqdXN0 IHJlc3VsdCBpbiBkcm9wcGVkIHBhY2tldHMuIENhbiB3ZSBlbnN1cmUgdGhhdCB0aGUgaGFuZHNo YWtlIHByb3RvY29sIGlzIHJvYnVzdCBhZ2FpbnN0IHRoYXQ/DQoNCi0tIENocmlzdGlhbiBIdWl0 ZW1hDQoNCg0K From nobody Sun Dec 27 23:32:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CE41A89E0 for ; Sun, 27 Dec 2015 23:32:08 -0800 (PST) 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 1XosqY3Cu_qT for ; Sun, 27 Dec 2015 23:32:06 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE301A89D3 for ; Sun, 27 Dec 2015 23:32:06 -0800 (PST) Received: by mail-qg0-x22e.google.com with SMTP id e32so50948441qgf.3 for ; Sun, 27 Dec 2015 23:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=WqdeJR+z4Sw5bkzPgDk/pW+K513bPPFubw4IwI+dRXo=; b=FOoWlLNCouMeO3PAkHtPO2z4FPxmgPRE37+coAyj/jaKcByQ5e+X+RrJvUMR25v2YL wPUJuLwtqsuY2StRjVg3SuACGJPec1M9/SpBPxNDj9Bx0ZWiSyZaZQa8Zpsi+LEUugqU fWElS8D0DhJufZVwZxXGf5tWtR5cFzoW+OQWzz+RqWNJziZYbn4qgT+YLFTxLrUs/ami +TsNPaHHGUjdTBKD2Wt1x40q2sajSKUmCEHW1w9+Yj2nRjgfi0e45zF/1V7XvgSzbCOV 4heD+OxzIX974Xw+FVNOKOZ4cXJ9d0zqls50LuBpHPe3s/QRAMhLjjiplmsBPA8bIqUZ akPg== X-Received: by 10.140.93.51 with SMTP id c48mr67743732qge.29.1451287925817; Sun, 27 Dec 2015 23:32:05 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id i136sm4675597qhc.42.2015.12.27.23.32.05 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 27 Dec 2015 23:32:05 -0800 (PST) From: Dave Garrett To: Christian Huitema Date: Mon, 28 Dec 2015 02:32:03 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201512270208.11253.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201512280232.04005.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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: Mon, 28 Dec 2015 07:32:08 -0000 On Sunday, December 27, 2015 11:55:16 pm Christian Huitema wrote: > On Saturday, December 26, 2015 9:08 PM, Dave Garrett wrote: > > On Thursday, December 24, 2015 08:08:25 pm Eric Rescorla wrote: > > > Well, this is a general requirement any time the record MAC is bad: > > > See > > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2ftlswg= =2Egith > > ub.io%2ftls13- > > spec%2f%23rfc.section.5.2.2&data=3D01%7c01%7chuitema%40microsoft.com%7 > > c57c8404a1f2f41a17f8a08d30e8c8243%7c72f988bf86f141af91ab2d7cd011db4 > > 7%7c1&sdata=3DnTdhU1cC6yaYfKvpIG4JR1vhTgs82gFYgVLJbPYskXQ%3d > > > "If the decryption fails, a fatal =E2=80=9Cbad_record_mac=E2=80=9D al= ert MUST be generated." > > > > > > On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett > > > wrote: > > > > The current text doesn't explicitly say how to handle 0-RTT data th= at it > > > > thinks it should be able to decrypt but can't. After rereading thin= gs a bit > > > > I think you're correct in that the correct course of action the spec > > > > currently expects is to abort, however implementers frequently err = on the > > > > side of working partially vs not at all when given any wiggle room.= A clear > > > > hard "MUST abort" on failed decrypt of 0RTT data would deal with th= is and > > > > avoid any other possible misunderstanding. Either do or do not; no = try. > > > > > > If you have suggested text, I'd be happy to see a PR. > >=20 > > Ok, I filed PR 393 with a couple sentences to clarify that 0-RTT record= s aren't > > allowed special treatment and errors on handling MUST NOT result in a 1= =2DRTT > > fall back. >=20 > Isn't that a part where TLS and DTLS will differ a lot? >=20 > For DTLS, we have to consider the packet injection threat. It is fairly e= asy to send some random bytes with a fake source to a UDP destination. Such= attacks should not cause the DTLS association to fail! The normal behavior= ought to be to just ignore UDP packets that fail to decrypt. This would ca= use 0-RTT rejects to just result in dropped packets. Can we ensure that the= handshake protocol is robust against that? One idea might be to include a hash of all early data records' ciphertext i= n the "early_data" extension. This lets them stay out of the handshake hash= yet still have their hash be covered by it. So long as servers verify all = successfully decrypted early data records against this hash before processi= ng them further, and abort if something is missing, then this could be done= safely. More complex, though. Dave From nobody Mon Dec 28 03:46:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E159F1A9062 for ; Mon, 28 Dec 2015 03:46:45 -0800 (PST) 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, HTML_MESSAGE=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 5ue3sA0JkUn3 for ; Mon, 28 Dec 2015 03:46:43 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F36B11A905E for ; Mon, 28 Dec 2015 03:46:42 -0800 (PST) Received: by mail-yk0-x229.google.com with SMTP id x67so99704126ykd.2 for ; Mon, 28 Dec 2015 03:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=D6MNgRw/Vd/wTuDLBhEg/XKzRYu2igE4eKfDlNRVZYA=; b=naaaC7NEwZA3upwX3rVtmkHM7hDBza5t/rwDyjOrSz5Aivy3mMInGPr7Gqs+qJEiWh HXA7XZVE6qGTcsPeWq7Hv1y2vbx2uwDoI13Fm73dNsjDsrsb7LCxZTqearQLTPxhfRSR /TYxULmsrStX+6F4pULKbyqIC1/N3Ln6rfUiEgpHcVIsSzksTwAzCpOx5+xrJsajDTsS rC+poOj+uVhelYCUt+Ko1sJE9LGhbh07ddBAFprwkiacLTVs2YVNnJcHmvFBVQf2lv2J M4GIBiCnfZCqVUk974MFjS63S+keSWWmGTLAeOAeSLX+t/JI7w+cp4UMwKqpmOHKwdIh v0Nw== 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=D6MNgRw/Vd/wTuDLBhEg/XKzRYu2igE4eKfDlNRVZYA=; b=BX0A0L0ljc8rLTPg3GHh8OFJfYBBszfN0j8K1tilN2iJJCmPA86s93DNEr49vrPHJ7 1YFc3l+vyEaIGtVA/yI5cIMlqOv0wlOctdHeuM9UUWwYhB1MXQdAxrO/TN6JgU7zG5eo OloHzqKM7VeqxuManuUbNTH+JwKFiKchifjbXVvQzYcaUoqozAHaKKmLXrjxQ5FnH8x8 oK1tkTi6Ifcu8uhNusA7ZnZysbErVjTRXyRC/oEXS4axwHxv7TzNdKXT+VJIi4u0Uhnp kQewkYnVcTbb9kah0SfPbgCWlHWgnlPX/rz5pG6alfOuiw3mzufPGRgeqqitJfa5v4yz jYbA== X-Gm-Message-State: ALoCoQlgbzW1iNIoUZ6Gz3hR7007igzMLi2p9jW1DUXKVTgjsYoHAFCWmapeFWjqmcrbH7cIj3Q99nTmStpqZ1xONBgyHYepXg== X-Received: by 10.129.153.3 with SMTP id q3mr45349737ywg.231.1451303202198; Mon, 28 Dec 2015 03:46:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Mon, 28 Dec 2015 03:46:02 -0800 (PST) In-Reply-To: References: <201512241748.25385.davemgarrett@gmail.com> <201512270208.11253.davemgarrett@gmail.com> From: Eric Rescorla Date: Mon, 28 Dec 2015 06:46:02 -0500 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=94eb2c0bbfaed46ae60527f3dbc1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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: Mon, 28 Dec 2015 11:46:46 -0000 --94eb2c0bbfaed46ae60527f3dbc1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Dec 27, 2015 at 11:55 PM, Christian Huitema wrote: > On Saturday, December 26, 2015 9:08 PM, Dave Garrett wrote: > > On Thursday, December 24, 2015 08:08:25 pm Eric Rescorla wrote: > > > Well, this is a general requirement any time the record MAC is bad: > > > See > > > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2ftlswg.g= ith > > ub.io%2ftls13- > > spec%2f%23rfc.section.5.2.2&data=3D01%7c01%7chuitema%40microsoft.com%7 > > c57c8404a1f2f41a17f8a08d30e8c8243%7c72f988bf86f141af91ab2d7cd011db4 > > 7%7c1&sdata=3DnTdhU1cC6yaYfKvpIG4JR1vhTgs82gFYgVLJbPYskXQ%3d > > > "If the decryption fails, a fatal =E2=80=9Cbad_record_mac=E2=80=9D al= ert MUST be > generated." > > > > > > On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett > > > wrote: > > > > The current text doesn't explicitly say how to handle 0-RTT data > that it > > > > thinks it should be able to decrypt but can't. After rereading > things a bit > > > > I think you're correct in that the correct course of action the spe= c > > > > currently expects is to abort, however implementers frequently err > on the > > > > side of working partially vs not at all when given any wiggle room. > A clear > > > > hard "MUST abort" on failed decrypt of 0RTT data would deal with > this and > > > > avoid any other possible misunderstanding. Either do or do not; no > try. > > > > > > If you have suggested text, I'd be happy to see a PR. > > > > Ok, I filed PR 393 with a couple sentences to clarify that 0-RTT record= s > aren't > > allowed special treatment and errors on handling MUST NOT result in a > 1-RTT > > fall back. > > Isn't that a part where TLS and DTLS will differ a lot? > > For DTLS, we have to consider the packet injection threat. It is fairly > easy to send some random bytes with a fake source to a UDP destination. > Such attacks should not cause the DTLS association to fail! The normal > behavior ought to be to just ignore UDP packets that fail to decrypt. Thi= s > would cause 0-RTT rejects to just result in dropped packets. Can we ensur= e > that the handshake protocol is robust against that? > We obviously need to distinguish here between handshake and application data messages, because DTLS is intended to allow loss of application data messages. WRT handshake messages, as I indicated before, I believe that there is enough information in the handshake messages to prevent removal. Namely: 1. The ClientHello contains an indication that 0-RTT handshake messages are coming. 2. The Client's 0-RTT Finished contains a MAC of all the Client's 0-RTT messages. 3. The Server's Finished contains a MAC of the ClientHello. Thus, provided that the client and server in fact share a configuration (which, again, is in the ClientHello) then the server knows at the time of receiving the first-flight Finished that he has (or has not) received all the client's 0-RTT Handshake messages. [0]. The more interesting question, however, is what drives the DTLS state machine forward to ensure progress in the face of innocuous loss. The basic DTLS design is that the receipt of the first message of the peer's next flight indicates receipt of the entire flight. In this case, then, the receipt of the ServerHello would indicate receipt of the Client's 0-RTT Finished. However, this would place a requirement that the server not *send* the ServerHello until that point, which we've left open in WIP-11 by not hashing in the 0-RTT plaintext. -Ekr [0] Note, however, that the client has to rely on the server to handle this properly. The reason --94eb2c0bbfaed46ae60527f3dbc1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Dec 27, 2015 at 11:55 PM, Christian Huitema &= lt;huitema@micro= soft.com> wrote:
On Saturday, December 26, 2015 9:08 PM, Dave Garrett wrote:
> On Thursday, December 24, 2015 08:08:25 pm Eric Rescorla wrote:
> > Well, this is a general requirement any time the record MAC is ba= d:
> > See
> https://na= 01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2ftlswg.gith
> ub.io%2ftls13-
> spec%2f%23rfc.section.5.2.2&data=3D01%7c01%7chuitema%40microsoft.com<= /a>%7
> c57c8404a1f2f41a17f8a08d30e8c8243%7c72f988bf86f141af91ab2d7cd011db4 > 7%7c1&sdata=3DnTdhU1cC6yaYfKvpIG4JR1vhTgs82gFYgVLJbPYskXQ%3d
> > "If the decryption fails, a fatal =E2=80=9C= bad_record_mac=E2=80=9D alert MUST be generated."
> >
> > On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett <davemgarrett@gmail.com>
> > wrote:
> > > The current text doesn't explicitly say how to handle 0-= RTT data that it
> > > thinks it should be able to decrypt but can't. After rer= eading things a bit
> > > I think you're correct in that the correct course of act= ion the spec
> > > currently expects is to abort, however implementers frequent= ly err on the
> > > side of working partially vs not at all when given any wiggl= e room. A clear
> > > hard "MUST abort" on failed decrypt of 0RTT data w= ould deal with this and
> > > avoid any other possible misunderstanding. Either do or do n= ot; no try.
> >
> > If you have suggested text, I'd be happy to see a PR.
>
> Ok, I filed PR 393 with a couple sentences to clarify that 0-RTT recor= ds aren't
> allowed special treatment and errors on handling MUST NOT result in a = 1-RTT
> fall back.

Isn't that a part where TLS and DTLS will differ a lot?

For DTLS, we have to consider the packet injection threat. It is fairly eas= y to send some random bytes with a fake source to a UDP destination. Such a= ttacks should not cause the DTLS association to fail! The normal behavior o= ught to be to just ignore UDP packets that fail to decrypt. This would caus= e 0-RTT rejects to just result in dropped packets. Can we ensure that the h= andshake protocol is robust against that?

We obviously need to distinguish here between handshake and application<= /div>
data messages, because DTLS is intended to allow loss of applicat= ion data
messages.

WRT handshake message= s, as I indicated before, I believe that there is
enough informat= ion in the handshake messages to prevent removal.
Namely:

1. The ClientHello contains an indication that 0-RTT hand= shake messages
are coming.
2. The Client's 0-RTT Fi= nished contains a MAC of all the Client's
0-RTT messages.
3. The Server's Finished contains a MAC of the ClientHello.

Thus, provided that the client and server in fact shar= e a configuration
(which, again, is in the ClientHello) then the = server knows at the time
of receiving the first-flight Finished t= hat he has (or has not) received
all the client's 0-RTT Hands= hake messages. [0].


The more intere= sting question, however, is what drives the DTLS state
machine fo= rward to ensure progress in the face of innocuous loss.
The basic= DTLS design is that the receipt of the first message of the
peer= 's next flight indicates receipt of the entire flight. In this case,
then, the receipt of the ServerHello would indicate receipt of the<= /div>
Client's 0-RTT Finished. However, this would place a requirem= ent
that the server not *send* the ServerHello until that point, = which we've
left open in WIP-11 by not hashing in the 0-RTT p= laintext.

-Ekr

[0] No= te, however, that the client has to rely on the server to handle this
=
properly. The reason

--94eb2c0bbfaed46ae60527f3dbc1-- From nobody Mon Dec 28 07:39:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2F81A016C for ; Mon, 28 Dec 2015 07:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 24uh2W0hFcks for ; Mon, 28 Dec 2015 07:39:07 -0800 (PST) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC06A1A016A for ; Mon, 28 Dec 2015 07:39:06 -0800 (PST) Received: by mail-qg0-x235.google.com with SMTP id 6so70643187qgy.1 for ; Mon, 28 Dec 2015 07:39:06 -0800 (PST) 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=DVN7VeKB0/5if1+Dmqi6K7CkB/CQECceXrvSy0rlyYY=; b=FF1i2rwVbOtk6ZQ76wckxCcbjKdK7DcDqvBxT8dW3JuM2rLju4TdNjrMMrGE+gWL68 XpinVgyMlnpXUB1CnEkXfIXmJnGkcXRoZ7hydaY41ebkbEBwGzj2zAgus7uq4RjqlxhC m0kkvytat7T76ljSDqnu/nEw4qhyxjfKyEv3W/aYUxBjpqfzVr27847nJhhER/XEbBiY QvwmjcGpw4fRq4JVz3tUPljvETZJivjrMDbekk0Nl454enKCt17SdHCYO2Aijz5c2aSb I+mO1DkkTfxz+8uTCL1CWFzvWd86eNQyeaL8Y5AHbJqYn/1u+3oyhq8gDQO8XJzgKPFR yUug== MIME-Version: 1.0 X-Received: by 10.140.106.37 with SMTP id d34mr72923783qgf.77.1451317145923; Mon, 28 Dec 2015 07:39:05 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.93.12 with HTTP; Mon, 28 Dec 2015 07:39:05 -0800 (PST) In-Reply-To: References: Date: Mon, 28 Dec 2015 07:39:05 -0800 X-Google-Sender-Auth: BKB9D6z0unClHHJxm_4K-r16AWI Message-ID: From: Adam Langley To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Dec 2015 15:39:08 -0000 On Tue, Dec 22, 2015 at 3:15 PM, Brian Smith wrote: > I agree with all of that in principle. In fact, I think that most of section > 2.3 should be removed in deference to the CFRG document, and only > TLS-specific concerns should be given. > > I still think there is value in requiring senders to send their public value > in the "normalized" form and for allowing (if not requiring) receivers to > reject, at least, public values >= q, for the reasons I gave in my previous > email. Ideally that would happen in the CFRG document. But, what is the > status of the CFRG document? I've heard that it's past the point where > changes will be accepted. The CFRG document is in AUTH48 right now so, indeed, it's probably too late for that sort of change. To give some background about why the CFRG document ended up the way it did: The curve25519 paper only mentions the extra bit to say: "Note that Curve25519 is not surjective: in particular, its final output bit is always 0 and need not be transmitted." [1]. It didn't specify whether it should be ignored or not and implementations started to differ on that point. Also, in order to keep the code simple, it didn't check for values >= 2^255-19. Both because that could be more code in the primitive itself, and because it would mean that the function would change from being total to partial. Some years ago, there was a small effort to align the different implementations around the same behaviour and ignoring the bit was chosen. I think that decision probably arose from changing the fewest things and also the thought that people might want to use the extra bit as a sign bit in the future. No implementations rejected values >= 2^255-19 from what I recall. Since the CFRG has standardised Curve25519, in practice the existing implementations will seed the implementation ecosystem. Changing something really subtle like the extra bit behaviour, or rejecting oversized values, without a clear need, doesn't seem to me to be worthwhile (or, perhaps, even achievable for a spec). So at this point I'd like to nail down the existing behaviour with tests, try to make it uniform across most implementations, and try to avoid other specs interpreting the byte strings. [1] http://cr.yp.to/ecdh/curve25519-20060209.pdf Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Mon Dec 28 11:34:47 2015 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B89F1AC3DB; Mon, 28 Dec 2015 11:34:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151228193446.28197.26273.idtracker@ietfa.amsl.com> Date: Mon, 28 Dec 2015 11:34:46 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-tls13-11.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: Mon, 28 Dec 2015 19:34:46 -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 : The Transport Layer Security (TLS) Protocol Version 1.3 Author : Eric Rescorla Filename : draft-ietf-tls-tls13-11.txt Pages : 115 Date : 2015-12-28 Abstract: This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-11 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 Mon Dec 28 11:53:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044BC1AC3F7 for ; Mon, 28 Dec 2015 11:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 YVb9BMB-bUBE for ; Mon, 28 Dec 2015 11:53:30 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ADEF1AC3F5 for ; Mon, 28 Dec 2015 11:53:30 -0800 (PST) Received: by mail-yk0-x236.google.com with SMTP id k129so89877689yke.0 for ; Mon, 28 Dec 2015 11:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type; bh=7CUiwMJrldr4HkNIvToCeIZw0prKv0YCeo3v9sa/0AA=; b=tepNnedM7v7K7B765xRJVCc8KNGAsoTz6QzU4V/p6icPiwr6Tje/dvzxDBMEmyrrB/ QdXg61NlPMfIoX/KlGawlskrYT4h5pHq+PagaCCqDD2ypGUxhGFHdsH4T9CDjSELgLJy WEVk289d6mqdxv6z3Pwof/yq75i21OXQyAQLFzxSk3t3e4UXydXhkvf33fo39/deXkmu Ilu1w3PAdvZQOdBgzQhjA6ziGGwkcSTEI2FfidEpFHWHWeS3OutwXULT5n9Y50W7p4tw flcai5dPL4zi2gwjCRoFlokr1V+UvvM+T3CuaSB5i/2iq4bgf67B4l/pTESUUjCYYEkY 9NiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=7CUiwMJrldr4HkNIvToCeIZw0prKv0YCeo3v9sa/0AA=; b=YEzcbpFLZfLXBarREUrARz1bsZmp4S2lky+JbmvRtPmZHDnsRsDlo7LlJKZRjr3OZV kGulC44/SB64UbH2RHWcnGZI7GSmEX/wkrt1vm/h+tmy6+g116c9RYrdW9oB5WyvXP9S S8yQI3yF+RHAjo2FqNPluKlv4GOmYGVUt2q0/hw2PXLazoTlFvc2LJloXomUjv9tdSxm hwlak1O8L7rihYHjPrVC/zUIayjpD2p7pbcZag5DYvH/T3h+G8g56PpSMnvYmIZFmTuy sl3N8EMb07X55LdGxBTxCGqdmgykzHcrlA8EK7gsscUY1TFAOatxw7snowM0SNAsIxZ8 fppQ== X-Gm-Message-State: ALoCoQmRkjyt1plTI90rTMrKLTqD6Wxk5UYTIlqSKOS04s+WhDVajOnBgnJczeW1CR30lXiVJJKnZQSlCGf+r9fERyAoyqhTAw== X-Received: by 10.129.79.87 with SMTP id d84mr40873172ywb.115.1451332409350; Mon, 28 Dec 2015 11:53:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Mon, 28 Dec 2015 11:52:49 -0800 (PST) From: Eric Rescorla Date: Mon, 28 Dec 2015 14:52:49 -0500 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114dc360b60a490527faa8a9 Archived-At: Subject: [TLS] TLS 1.3 draft -11 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Dec 2015 19:53:32 -0000 --001a114dc360b60a490527faa8a9 Content-Type: text/plain; charset=UTF-8 Folks, In the spirit of making a useful checkpoint, I just posted the latest version of the editor's draft as draft-11. Here's the major changes: - Port the CFRG curves & signatures work from RFC4492bis. - Remove sequence number and version from additional_data, which is now empty. - Reorder values in HkdfLabel. - Add support for version anti-downgrade mechanism. - Update IANA considerations section and relax some of the policies. - Unify authentication modes. Add post-handshake client authentication. - Remove early_handshake content type. Terminate 0-RTT data with an alert. - Reset sequence number upon key change (as proposed by Fournet et al.) The major open issues I am aware of are: - Figuring out whether we want to hash in additional data from the 0-RTT exchange into the 1-RTT handshake (Issue #351, some on-list comments by Ilari, and the discussion over the past few days about DTLS). I believe that the conclusion of these discussions was that there was not a clear security issue here and that there were different views of the aesthetics of inclusion versus exclusion. Arguments/corrections welcome here. - Closing on Encrypted SNI. My sense is that to the extent to which people have enthusiasm for this, it's for the proposal that I posted on 12/5: https://www.ietf.org/mail-archive/web/tls/current/msg18633.html Chairs: can you please help drive this to conclusion? - Details of state pickling for stateless reject. I owe the list a proposal here. - We still need clearer text around data volumes, which might, I suppose, result in concluding that we don't need rekey. I'll send mail about this separately shortly. - Hugo's proposal to explicitly include the random values in the handshake hashes. Chairs, can you please help drive this to conclusion as well? -Ekr --001a114dc360b60a490527faa8a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,

In the spirit of making a useful= checkpoint, I just posted the latest version of the
editor's= draft as draft-11. Here's the major changes:

=
- Port the CFRG curves & signatures work from RFC44= 92bis.

- Remove sequence number and version from a= dditional_data, which
=C2=A0 is now empty.

- Reorder values in HkdfLabel.

- Add support fo= r version anti-downgrade mechanism.

- Update IANA = considerations section and relax some of the policies.

=
- Unify authentication modes. Add post-handshake client authentication= .

- Remove early_handshake content type. Terminate= 0-RTT data with
=C2=A0 an alert.

- Rese= t sequence number upon key change (as proposed by Fournet et al.)


The major open issues I am aware of ar= e:

- Figuring out whether we want to hash in addit= ional data from the 0-RTT exchange
=C2=A0 into the 1-RTT handshak= e (Issue #351, some on-list comments by Ilari, and the
=C2=A0 dis= cussion over the past few days about DTLS). I believe that the conclusion o= f
=C2=A0 these discussions was that there was not a clear securit= y issue here and that
=C2=A0 there were different views of the ae= sthetics of inclusion versus exclusion.
=C2=A0 Arguments/correcti= ons welcome here.

- Closing on Encrypted SNI. My s= ense is that to the extent to which people have
=C2=A0 enthusiasm= for this, it's for the proposal that I posted on 12/5:
=C2=A0 Chairs: can you please help drive this to conclusion?

- Details of state pickling for stateless reject. I = owe the list a proposal here.

- We still need clea= rer text around data volumes, which might, I suppose, result
=C2= =A0 in concluding that we don't need rekey. I'll send mail about th= is separately
=C2=A0 shortly.

- Hugo'= ;s proposal to explicitly include the random values in the handshake
<= div>=C2=A0 hashes. Chairs, can you please help drive this to conclusion as = well?

-Ekr



=C2=A0=C2=A0




--001a114dc360b60a490527faa8a9-- From nobody Mon Dec 28 11:55:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD491AC3F9 for ; Mon, 28 Dec 2015 11:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 ceK65gXmokmb for ; Mon, 28 Dec 2015 11:55:15 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806681AC3F7 for ; Mon, 28 Dec 2015 11:55:15 -0800 (PST) Received: by mail-yk0-x230.google.com with SMTP id a85so35178598ykb.1 for ; Mon, 28 Dec 2015 11:55:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZE+WgF+fB0Ho3CO6o3+jW0dgBBtZPsvER5242YufTQA=; b=dtlp/3DU8vdrwhUC3r/RrXZdCfWzUI90SFsr8RlRlbxpM9SdW4KDhIJi2B/IX9mM/g aqOucoIKr5+Ms7lDn7JYne4LbhX9dLBkFr0EaMzq5ambtjWcy5fAjTvcgW3PQyl1S7EK EfkppuYnc6c2zmhomwLDK6nQA+3ISyKptxLQ5284T66t/zgKZHO1+aByJ7EqgC4pnsy+ J4TsQRnWt32f4E15dssda1aO7Ry3Kiw0+gXa+qNKxSNfZ+ABIvMHC/+lukE/IPtke4dq gcYey3fDcVdSJGAoSowXP20d/IR73bkutdWC3TjFOHjo8BZ1j9FCUOQyKldYfzfYrxLc 4Zlw== 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=ZE+WgF+fB0Ho3CO6o3+jW0dgBBtZPsvER5242YufTQA=; b=PEl3pPV6qIVRRJF+4gV48sJ/4J79zSGAnK1h6zhwWFImsjq1pO65sUJSDesX2hCvWp TvkKm7wgwmhBfTsWZz1JYhnrlv+CGZelp/I8TRNbdY6w1TY1iyWWKjAJjxvlyTCu7IGE 37brEkWUt6fxAfbzEY6lG13ktRz1MHvIne96XY9XjnhuLbXNWx8+N6lCmiDkquocUrII tffgcQXQSoeMJ0pXIQFT7Z6HoeuqmaPfNyodRpxiGzU7Fnt5XMx0f2TjaEL5v8TtTZU8 AO0v/gozg/j2mF+Y42wL9I9bRba4HBvLMI7/lU8UxEesPmHqXuvRPUyCuOQko6nr6GSh exSg== X-Gm-Message-State: ALoCoQnBKzrpJHkRxCgN0pp7bx+4btjXt4iBAGhQd9iOMLerrhoTTy9XkzRYLN20wNKpAixdoYPiAiDYzKKgUWmKwQVgrYDl8Q== X-Received: by 10.129.46.208 with SMTP id u199mr41187051ywu.129.1451332514690; Mon, 28 Dec 2015 11:55:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Mon, 28 Dec 2015 11:54:35 -0800 (PST) In-Reply-To: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> References: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Mon, 28 Dec 2015 14:54:35 -0500 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=001a11408592fd6a8e0527faaeca Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Mon, 28 Dec 2015 19:55:19 -0000 --001a11408592fd6a8e0527faaeca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Scott, Henrick, Are you persuaded by Watson's analysis? Thanks, -Ekr On Mon, Dec 21, 2015 at 7:41 AM, Hubert Kario wrote: > On Tuesday 15 December 2015 20:01:58 Bill Frantz wrote: > > So we have to trade off the risks of too much data vs. the risks > > of a complex rekey protocol vs. the risks having the big data > > applications build new connections every 2**36 or so bytes. > > > > If we don't have rekeying, then the big data applications are > > the only ones at risk. If we do, it may be a wedge which can > > compromise all users. > > if the rekey doesn't allow the application to change authentication > tokens (as it now stands), then rekey is much more secure than > renegotiation was in TLS <=3D 1.2 > > so if we include rekeying in TLS, I'd suggest to set its limit to > something fairly low for dig data transfers, that is gigabytes, not > terabytes, otherwise we'll be introducing code that is simply not tested > for interoperability > > (with AES-NI you can easily transfer gigabytes in just few minutes) > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11408592fd6a8e0527faaeca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Scott, Henrick,

Are you persuaded by Wa= tson's analysis?

Thanks,
-Ekr
<= div>



On Mon, Dec 21, 2015 at 7:41 AM, Hubert Ka= rio <hkario@redhat.com> wrote:
On Tuesday 15 December 2015 20:01:58 Bill Frantz wrot= e:
> So we have to trade off the risks of too much data vs. the risks
> of a complex rekey protocol vs. the risks having the big data
> applications build new connections every 2**36 or so bytes.
>
> If we don't have rekeying, then the big data applications are
> the only ones at risk. If we do, it may be a wedge which can
> compromise all users.

if the rekey doesn't allow the application to change authenticat= ion
tokens (as it now stands), then rekey is much more secure than
renegotiation was in TLS <=3D 1.2

so if we include rekeying in TLS, I'd suggest to set its limit to
something fairly low for dig data transfers, that is gigabytes, not
terabytes, otherwise we'll be introducing code that is simply not teste= d
for interoperability

(with AES-NI you can easily transfer gigabytes in just few minutes)
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--001a11408592fd6a8e0527faaeca-- From nobody Mon Dec 28 12:08:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717671AC414 for ; Mon, 28 Dec 2015 12:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.012 X-Spam-Level: X-Spam-Status: No, score=-5.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-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 SpxzY8kZOSRm for ; Mon, 28 Dec 2015 12:08:13 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E6901AC412 for ; Mon, 28 Dec 2015 12:08:13 -0800 (PST) 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 (Postfix) with ESMTPS id 1617BC0B7E0E for ; Mon, 28 Dec 2015 20:08:13 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-204-34.brq.redhat.com [10.40.204.34]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBSK8AZp013190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Dec 2015 15:08:12 -0500 To: Hubert Kario , tls@ietf.org References: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> From: Florian Weimer Message-ID: <568196AA.4040100@redhat.com> Date: Mon, 28 Dec 2015 21:08:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [TLS] Data volume 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: Mon, 28 Dec 2015 20:08:14 -0000 On 12/21/2015 01:41 PM, Hubert Kario wrote: > if the rekey doesn't allow the application to change authentication > tokens (as it now stands), then rekey is much more secure than > renegotiation was in TLS <= 1.2 You still have the added complexity that during rekey, you need to temporarily switch from mere sending or receiving to at least half-duplex interaction. Florian From nobody Mon Dec 28 12:11:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9E31AC422 for ; Mon, 28 Dec 2015 12:11:55 -0800 (PST) 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, HTML_MESSAGE=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 l8-yV4hSvgQM for ; Mon, 28 Dec 2015 12:11:54 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EEFF1AC41F for ; Mon, 28 Dec 2015 12:11:54 -0800 (PST) Received: by mail-yk0-x234.google.com with SMTP id a85so35547654ykb.1 for ; Mon, 28 Dec 2015 12:11:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XJ3oW5E3BwCbIRhX6x2vbR3KrVwoCZFtd02T5qa1UR4=; b=g1Fsy/Rfz/Q8CbbuPnNrY+9ZfgWBZfAYP+U4EVkdWmywZmnxsChuuEE8explZ0qfhs /DpTKbO675pvE/GZH1mv4RKcRBRjsM+dYx2ITc6XXneS1W6eDBeeC6qMgO6v7pNGK2XH q8OCWnkBVG+u0zYzH9RaSf8q2BfpBCy7OI5LzvppFjLw1cZ390xZhUhps/1wi7ZwVUsi JLvowI8F0pnZhWVxFi/xbSeC9IwTAEpfUNmy0z2HmeSKCgZ/JMBGOZ9CJYuipusfK3kN s4xmKJSFaGvJpESvOnNJVWPF08HALlfn3GvQOTcF6hlbwOKlAmV3nwNwluqKUxrNtEPy YP3A== 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=XJ3oW5E3BwCbIRhX6x2vbR3KrVwoCZFtd02T5qa1UR4=; b=IT0rml83eakkuomEb4Wk90BcZ68ada8qt7ftVi9RhHyCglj4JefGmvF52V9rdgsb0v 6MVau3pmN7U2UGn4HjOYaGqX1Gl/drm8xHMOq1j7p+h6cfcZ2XMUuaoAok8ipnHKNW+X aXb3RyCZT0rN7Vpw+AvRgQ1bCntafJpDWDda7+qIWa7qvreX3ozgATgPHMdeRtO4warm JOp3CoOd1XV/+b/kfilxcbaLmX1Z29bsIjH5KtNM1Wuw9PzmMspDLCPK+vZAipAahXc2 nXplhHyNmiWkCF5vgpk9kLElmq830j3vZM9YNYgBsPV8NI2M73bAbiONHi8vPg87dHPx JqwQ== X-Gm-Message-State: ALoCoQnAeiudxHG7nlrexTCtGdcgssiusC8LOHP/1UGpAg/Cbzjkj226UY8wjZ1pJp75KGS3+DlxD8QcZBI6aOl6P54TCxBeIQ== X-Received: by 10.129.79.87 with SMTP id d84mr40933168ywb.115.1451333513300; Mon, 28 Dec 2015 12:11:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Mon, 28 Dec 2015 12:11:13 -0800 (PST) In-Reply-To: <568196AA.4040100@redhat.com> References: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> <568196AA.4040100@redhat.com> From: Eric Rescorla Date: Mon, 28 Dec 2015 15:11:13 -0500 Message-ID: To: Florian Weimer Content-Type: multipart/alternative; boundary=001a114dc36082f55d0527faea8d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Mon, 28 Dec 2015 20:11:55 -0000 --001a114dc36082f55d0527faea8d Content-Type: text/plain; charset=UTF-8 On Mon, Dec 28, 2015 at 3:08 PM, Florian Weimer wrote: > On 12/21/2015 01:41 PM, Hubert Kario wrote: > > > if the rekey doesn't allow the application to change authentication > > tokens (as it now stands), then rekey is much more secure than > > renegotiation was in TLS <= 1.2 > > You still have the added complexity that during rekey, you need to > temporarily switch from mere sending or receiving to at least > half-duplex interaction. > That's not intended. Indeed, you need to be able to handle the old key in order to send/receive the KeyUpdate. Can you elaborate on your concern? -Ekr --001a114dc36082f55d0527faea8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 28, 2015 at 3:08 PM, Florian Weimer <<= a href=3D"mailto:fweimer@redhat.com" target=3D"_blank">fweimer@redhat.com> wrote:
On = 12/21/2015 01:41 PM, Hubert Kario wrote:

> if the rekey doesn't allow the application to change authenticatio= n
> tokens (as it now stands), then rekey is much more secure than
> renegotiation was in TLS <=3D 1.2

You still have the added complexity that during rekey, you need to temporarily switch from mere sending or receiving to at least
half-duplex interaction.

That's not= intended. Indeed, you need to be able to handle the old key=C2=A0
in order to send/receive the KeyUpdate. Can you elaborate on your concern= ?

-Ekr


--001a114dc36082f55d0527faea8d-- From nobody Mon Dec 28 12:33:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D8B1AC43A for ; Mon, 28 Dec 2015 12:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-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 qJpRsqhumT6l for ; Mon, 28 Dec 2015 12:33:05 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60DB61AC442 for ; Mon, 28 Dec 2015 12:33:05 -0800 (PST) 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 (Postfix) with ESMTPS id CA4ED8F2F2; Mon, 28 Dec 2015 20:33:03 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-204-34.brq.redhat.com [10.40.204.34]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBSKX1fN021200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Dec 2015 15:33:02 -0500 To: Eric Rescorla References: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> <568196AA.4040100@redhat.com> From: Florian Weimer X-Enigmail-Draft-Status: N1110 Message-ID: <56819C7C.2040804@redhat.com> Date: Mon, 28 Dec 2015 21:33:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Mon, 28 Dec 2015 20:33:07 -0000 On 12/28/2015 09:11 PM, Eric Rescorla wrote: >> You still have the added complexity that during rekey, you need to >> temporarily switch from mere sending or receiving to at least >> half-duplex interaction. >> > > That's not intended. Indeed, you need to be able to handle the old key > in order to send/receive the KeyUpdate. Can you elaborate on your concern? Ah, so you want to keep the current mechanism and not inject fresh randomness? Isn't this fairly risky? Florian From nobody Mon Dec 28 12:37:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4A81AC44B for ; Mon, 28 Dec 2015 12:37:18 -0800 (PST) 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, HTML_MESSAGE=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 gEuBSZYzDHec for ; Mon, 28 Dec 2015 12:37:17 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C86E1AC44A for ; Mon, 28 Dec 2015 12:37:17 -0800 (PST) Received: by mail-yk0-x235.google.com with SMTP id x67so111683597ykd.2 for ; Mon, 28 Dec 2015 12:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sY7msiXysqT54DAXhmkCyU7OZghGxHgxJuLdLQWVPp4=; b=AcPHlz26xmtjWEMazAnERLYgcRdVQpjiPygqlTqk5sN/zcxPuBTj1NCIyz86fuhNrQ qKMyRocj61chdWHoZUGwX6DZcBCg4rGI1wgxRs5eTSEpksTC8A22pZN0XZ5uNJZY/aWU zYbY9Yl2/fJ+Bp9tWWEYWEzQnCGoFk1xgx0Wuh+nMx2hRqTQrbKQD56b/ZPDRP8mQ7ZX 0AibT256MZBVh+W3JAEeMOZr+r0ce9+5enzLVz0NvQChr7MmClx+UDmA7MhCYH5uF3Vz cHE4wtrGDbk5IANxbt9PGEwnbIB3uF6kcmHowRpJ6EsFqJt+ZTlNjiO4YukgWLEDJzQ9 /u3g== 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=sY7msiXysqT54DAXhmkCyU7OZghGxHgxJuLdLQWVPp4=; b=O2fxDyYV9JZVuCuZIKfPafTVl9UOhzQwJaTC87zgWU1i2BusOTlmH4JcIYpeHW59wj v2dI9QMl9MjuDpb3g93EDwH6y+7UuVz20D0mlgklMJ+9z+iYeQBsUl2pHGLJDlc0B/RS g30Ai8OPOXGg19aImF7wwgxD3zRxn+LXl45Joy3K0FhMmzDySoOrV5nLzppab5WElJ+t wwO8OiqETaFgKjvjljPpgrcQZSbBO3rl/6oxZsEnJrEeFlolLHXG9/eJfvnR8XLfdvKt 4w+ndDL8hRXxGxD50fS+v7RLOktg9A1X5n1GUkpBne95mUymyt4Q3HKXNnVljpTs5QHg UQtQ== X-Gm-Message-State: ALoCoQn+5wEbY0g2oJwEiPTBmEF9VFbKXbPIhuqC43HfyOcEsWW8sDXTZ7T55jf4cB80HdF+nPfuwXCTJvNUeEozuXxwrRKPPA== X-Received: by 10.129.153.3 with SMTP id q3mr47336622ywg.231.1451335036426; Mon, 28 Dec 2015 12:37:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Mon, 28 Dec 2015 12:36:36 -0800 (PST) In-Reply-To: <56819C7C.2040804@redhat.com> References: <1575673.4lLVr77Sve@pintsize.usersys.redhat.com> <568196AA.4040100@redhat.com> <56819C7C.2040804@redhat.com> From: Eric Rescorla Date: Mon, 28 Dec 2015 15:36:36 -0500 Message-ID: To: Florian Weimer Content-Type: multipart/alternative; boundary=94eb2c0bbfae4c04720527fb4528 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Mon, 28 Dec 2015 20:37:18 -0000 --94eb2c0bbfae4c04720527fb4528 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 28, 2015 at 3:33 PM, Florian Weimer wrote: > On 12/28/2015 09:11 PM, Eric Rescorla wrote: > > >> You still have the added complexity that during rekey, you need to > >> temporarily switch from mere sending or receiving to at least > >> half-duplex interaction. > >> > > > > That's not intended. Indeed, you need to be able to handle the old key > > in order to send/receive the KeyUpdate. Can you elaborate on your > concern? > > Ah, so you want to keep the current mechanism and not inject fresh > randomness? Isn't this fairly risky? Can you explain the risk you are concerned about in more detail? -Ekr --94eb2c0bbfae4c04720527fb4528 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 28, 2015 at 3:33 PM, Florian Weimer <<= a href=3D"mailto:fweimer@redhat.com" target=3D"_blank">fweimer@redhat.com> wrote:
On = 12/28/2015 09:11 PM, Eric Rescorla wrote:

>> You still have the added complexity that during rekey, you need to=
>> temporarily switch from mere sending or receiving to at least
>> half-duplex interaction.
>>
>
> That's not intended. Indeed, you need to be able to handle the old= key
> in order to send/receive the KeyUpdate. Can you elaborate on your conc= ern?

Ah, so you want to keep the current mechanism and not inject fresh randomness?=C2=A0 Isn't this fairly risky?

<= div>Can you explain the risk you are concerned about in more detail?

-Ekr


--94eb2c0bbfae4c04720527fb4528-- From nobody Mon Dec 28 12:41:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57791AC529 for ; Mon, 28 Dec 2015 12:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.808 X-Spam-Level: X-Spam-Status: No, score=-2.808 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 w2iRL_rFU3uP for ; Mon, 28 Dec 2015 12:40:57 -0800 (PST) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id E88CD1AC44A for ; Mon, 28 Dec 2015 12:40:56 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id tBSKet69010342; Mon, 28 Dec 2015 15:40:55 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Eric Rescorla , Florian Weimer Thread-Topic: [TLS] Data volume limits Thread-Index: AdFBsAxode9nh48KlkmRxpLGJ4HFmw== Date: Mon, 28 Dec 2015 20:40:54 +0000 Message-ID: <20151228204103.17780804.52985.42662@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============1554088141==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2015-12-28_13:2015-12-28,2015-12-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1511060000 definitions=main-1512280387 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Mon, 28 Dec 2015 20:40:59 -0000 --===============1554088141== Content-Type: multipart/alternative; boundary="===============0517241157==" MIME-Version: 1.0 --===============0517241157== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 T2ZmLWhhbmQsIGtleSB1cGRhdGUgb3IgcmUta2V5IHdpdGhvdXQgbmV3L2ZyZXNo4oCOIHJhbmRv bW5lc3Mgc291bmRzIHdlaXJkLgoKU2VudMKgZnJvbcKgbXnCoEJsYWNrQmVycnnCoDEwwqBzbWFy dHBob25lwqBvbsKgdGhlIFZlcml6b27CoFdpcmVsZXNzwqA0R8KgTFRFwqBuZXR3b3JrLgpGcm9t OiBFcmljIFJlc2NvcmxhClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMjgsIDIwMTUgMTU6MzcKVG86 IEZsb3JpYW4gV2VpbWVyCkNjOiB0bHNAaWV0Zi5vcmcKU3ViamVjdDogUmU6IFtUTFNdIERhdGEg dm9sdW1lIGxpbWl0cwoKCgpPbiBNb24sIERlYyAyOCwgMjAxNSBhdCAzOjMzIFBNLCBGbG9yaWFu IFdlaW1lciA8ZndlaW1lckByZWRoYXQuY29tPiB3cm90ZToKT24gMTIvMjgvMjAxNSAwOToxMSBQ TSwgRXJpYyBSZXNjb3JsYSB3cm90ZToKCj4+IFlvdSBzdGlsbCBoYXZlIHRoZSBhZGRlZCBjb21w bGV4aXR5IHRoYXQgZHVyaW5nIHJla2V5LCB5b3UgbmVlZCB0bwo+PiB0ZW1wb3JhcmlseSBzd2l0 Y2ggZnJvbSBtZXJlIHNlbmRpbmcgb3IgcmVjZWl2aW5nIHRvIGF0IGxlYXN0Cj4+IGhhbGYtZHVw bGV4IGludGVyYWN0aW9uLgo+Pgo+Cj4gVGhhdCdzIG5vdCBpbnRlbmRlZC4gSW5kZWVkLCB5b3Ug bmVlZCB0byBiZSBhYmxlIHRvIGhhbmRsZSB0aGUgb2xkIGtleQo+IGluIG9yZGVyIHRvIHNlbmQv cmVjZWl2ZSB0aGUgS2V5VXBkYXRlLiBDYW4geW91IGVsYWJvcmF0ZSBvbiB5b3VyIGNvbmNlcm4/ CgpBaCwgc28geW91IHdhbnQgdG8ga2VlcCB0aGUgY3VycmVudCBtZWNoYW5pc20gYW5kIG5vdCBp bmplY3QgZnJlc2gKcmFuZG9tbmVzcz/CoCBJc24ndCB0aGlzIGZhaXJseSByaXNreT8KCkNhbiB5 b3UgZXhwbGFpbiB0aGUgcmlzayB5b3UgYXJlIGNvbmNlcm5lZCBhYm91dCBpbiBtb3JlIGRldGFp bD8KCi1Fa3IKCgoK --===============0517241157== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable =
Off-hand, key u= pdate or re-key without new/fresh=E2=80=8E randomness sounds weird.
= =

= =
=
Sent from my BlackBe= rry 10 smartphone on the Verizon Wireless&nbs= p;4G LTE network.
= = =
From: Eric Rescorla
= Sent: Monday, December 28, 2015 15:37
To: Florian W= eimer
Cc: tls@ietf.org
Subject: Re: [TLS]= Data volume limits



On Mon, Dec 28, 2015 at 3:33 PM, Florian Weimer = <fweimer@redhat.com>= wrote:
On 12/28/2015 09:11 PM, Eric Rescorla wrote:

>> You still have the added complexity that during rekey, you need to=
>> temporarily switch from mere sending or receiving to at least
>> half-duplex interaction.
>>
>
> That's not intended. Indeed, you need to be able to handle the old key=
> in order to send/receive the KeyUpdate. Can you elaborate on your conc= ern?

Ah, so you want to keep the current mechanism and not inject fresh randomness?  Isn't this fairly risky?

Can you explain the risk you are concerned about in more detail?

-Ekr



--===============0517241157==-- --===============1554088141== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKTM8n7QAAAABB0TANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE1MDYwNTE4MTY0NFoXDTE2MDYwNDE4MTY0NFowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDQ 0ZYk84x0NrbLSMf9w+9rvO8Z3d5dfpynEt9it4HkQ3Fht5wpD1DOICbdPmcuoNGv73LUI6oRn7XT CnAFOeW9dGZetOUBIL44l0BoMYlUOvqOhtXUIoxm6PNbnDsYW3HpNuiskGO+jjH5CrvSFsZ//GHA dMGsQpRNBU7ZHCoOZF7+rv9RUh5pN5OgKumv9p24nWtGHNR1AHHDjB50Df9/1DVGhpe6aqf5DBhe f+1rf/dgAhjFSzrj3lTgNuczkZcB9Xs6fktq1jRCuwCdVTXQ/xgM5I3FHnVP73QEccOFR9qfdEVA 5IT7jo/7hMIvOBMWUJGOP7BpYXJd4VKj8CxLAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUr3pideNu 8mmOhHY8C2sJnlo/HVAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAKVaDwP2SaWtXtIINTrHpvDXC9dslWAv Tfg3TmHrQMtlKM6GQqkgIzF4WMZgM64RyUOqEnXrDcD7a3GPrcf8zDjRnsTiYaGkzhEUb/do5igL Al5x+FwAvhwvEuLJwHpAk0sfbxfX4lxY1S1YUngS+5PXGJbbFaNPAOefDG8jGgaM4TJ1weWlLT8F /MJudL6L6azCfOWQZhxpnT037XWGPeUfuqNnmwkwwlrCQB2QYgLQJtlUZQPqnb8Y2hd6OfhE7qvv /fcvX7i+Q4UKh3xGlMN2QHoX0Sk9sxxc4vgJnKk7MhaufGtOuNJLZlSfzCQRGd9Zprq9M+ROXuwN u72bKQkwggTqMIID0qADAgECAgpMzyftAAAAAEHRMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTUwNjA1MTgxNjQ0WhcNMTYwNjA0MTgxNjQ0WjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANDRliTzjHQ2tstIx/3D72u87xnd3l1+nKcS32K3geRDcWG3nCkPUM4gJt0+Zy6g0a/v ctQjqhGftdMKcAU55b10Zl605QEgvjiXQGgxiVQ6+o6G1dQijGbo81ucOxhbcek26KyQY76OMfkK u9IWxn/8YcB0waxClE0FTtkcKg5kXv6u/1FSHmk3k6Aq6a/2nbida0Yc1HUAccOMHnQN/3/UNUaG l7pqp/kMGF5/7Wt/92ACGMVLOuPeVOA25zORlwH1ezp+S2rWNEK7AJ1VNdD/GAzkjcUedU/vdARx w4VH2p90RUDkhPuOj/uEwi84ExZQkY4/sGlhcl3hUqPwLEsCAwEAAaOCAbIwggGuMB0GA1UdDgQW BBSvemJ1427yaY6EdjwLawmeWj8dUDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEApVoPA/ZJpa1e0gg1Osem 8NcL12yVYC9N+DdOYetAy2UozoZCqSAjMXhYxmAzrhHJQ6oSdesNwPtrcY+tx/zMONGexOJhoaTO ERRv92jmKAsCXnH4XAC+HC8S4snAekCTSx9vF9fiXFjVLVhSeBL7k9cYltsVo08A558MbyMaBozh MnXB5aUtPwX8wm50vovprMJ85ZBmHGmdPTftdYY95R+6o2ebCTDCWsJAHZBiAtAm2VRlA+qdvxja F3o5+ETuq+/99y9fuL5DhQqHfEaUw3ZAehfRKT2zHFzi+AmcqTsyFq58a0640ktmVJ/MJBEZ31mm ur0z5E5e7A27vZspCTCCBO0wggPVoAMCAQICCihwejIAAAAALQcwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNTAxMjMxNzQ5MjlaFw0xNjAxMjMxNzQ5MjlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxfkXLPYTTuYb5RNGHpbanlxlFtbt0VTBuP9moOidhYHLDicTmcv5vuxX mHwqN12Kzasev9yGZg0mJZ9yZ8cz4qJw3GytkyfcQDqFpa1MpAIYFJfjwjvGoQ1eWHNLZjM3+TFw a7Lm9J1MiXg5MTlGNiHefA9VFc814fSr43PmQnAURaFYgIJ+zM557ryvGOZuy6K9aC1ksTTVMqff IAuBKXRy5wPMj9Vqpja9MfmLLIyYBIiH2RasfBr79jqrR2hRh4e2OvljliGVCzGgHPSSRKvHLZ7P ZhiEZXX9iTBXDbGoUCQ4YFLKZj+nNVs/Tq1MbIMJxkOX3iKvXP+GGWBGfwIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFEdIXm5OIutOt2J6RBFV8kFMn0hTMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQA4puc4 02/4d3mv+ugzTOsEpotU4vRdn9vwK3tmu2vRPyD135Xod/ZVRu7k2p3hCTEh8w5bZAeZOg2DL/7d vJ7UJtoyyPWnTMHHA5SkkdriA7IgO46HYk8W6i/2kYvlguMm1loV7s0m5DHrGsreUACqbiiwK+53 sH2WlsfMz51lNZ1mQWyUe3CyoFE2hIkLvzZQliBSSAvckYc3vikeNbyGvu54kJ1ADY6GAgrt9mfM YMYSuJEK+bXlFVDQ6Ao9Nse/NRhX8ApJ8abFhJveTljNYmlyghifHIoqLpRM5LGVKyB3SJiEmkFV fl3Zm3Hdzh+svHzZdZmXV5/LMTSXPv4NMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgpMzyftAAAAAEHRMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTIyODIwNDEwMVowLwYJKoZIhvcNAQkEMSIEID0cL+zm/vR1 /mOwfXrppUdbinCTNXm5YrRZ8jwqCRPmMAsGCSqGSIb3DQEBCwSCAQAPRsnRQ7tUEkO+KQHUmKgS QE/QOzYX30sFIVtb0jPu1tucivGAHncM0IQO0yCHtRKgd6wds/JKDAq2lu0coQAFIZpaUWaHh9gS N3d7/XodcEz84sUw4DILYjLTpv8/nUzj/Nnbpx+MbJ5y/vh761Pl4b7FMl2nrqZssmch7VnTEfXK tBI7RKXnUwi9Jc3J/5m4/WV4meKHjRUzGEUeVRUUPtcH6sak2Aw53HzkflFR7PQUatnRMKJ/iXvm b9n46mLm7v2qhLRmYsGxBn3R6d3uyVnBdCHVDULPxiRDaQYFr1xu9C1wb5BGmZ0M85prVDxw8rKH rV+akRFF3P1pmp5kAAAAAAAA --===============1554088141==-- From nobody Mon Dec 28 12:47:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090101ACC8C for ; Mon, 28 Dec 2015 12:47:51 -0800 (PST) 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, HTML_MESSAGE=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 7sKwrQkxPru1 for ; Mon, 28 Dec 2015 12:47:50 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E371AC444 for ; Mon, 28 Dec 2015 12:47:49 -0800 (PST) Received: by mail-yk0-x22e.google.com with SMTP id k129so91029497yke.0 for ; Mon, 28 Dec 2015 12:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lryks1V/ARxZftMBQAf5QM4Oz43UZpBQOV0ge4L0LLs=; b=xbPkdZ/Xu5ItIleb/3eqV852DPVRdam8LbVibndz9CWjhF38uBI/rs5X/VIkTx2145 B9ARTVOdU3RJcsOTCbXzCn3yl8QkDDgSk2qjwASzXJWieyC9aFzR7qxrq/GG0RmeUosi GgTkUrjxSqGkInjM44m7GYY71Nhc6FL7k31+jmnDrpNR3MvQYT23xkJgK/0qf8NXQVvR /WBlkaqZd60WxZMxhCJkdXfGrWLbOtmHqQ9W3CPRkvm5lalNInPrRzYuvcbIPYPcMSbd IznoM33ycHMyFDs/5a8V7/WE7+EuNzdNcpLMrbuq1OnArpwQcejbB67Znb9W1vaBwsCM DQ9Q== 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=lryks1V/ARxZftMBQAf5QM4Oz43UZpBQOV0ge4L0LLs=; b=flsr/0CiybaR8MeYelv3pjZZakr8PaZjRtACBceniCNEcfRsFda1LNQ5+lRMWqNmZF xEVU5V1QWE3AChRFU9wlnWbPvjk2AuBD8SQEqr3NQBjxyEtTkDw6By6e6TYGJPF9S1Pt 4eiCtEYMIsUZZNr0ZowZk0D6PongcwzycuwIv/PWvQtGhJz5hxCKd/9eK6KkMCgSXWcY LLrBblH+D8ondiZk1ae4cZ6fOD02OG9ktSowUwbM4spD7pTYRqRvokMXNjnymbqDcDIa yE0hl+vV77Z3jKwepLhiNWuwCcvyRgWTmQ/TrEHnq5INtN890D8zVKKS21syO12Xu8XW a7bA== X-Gm-Message-State: ALoCoQnWJCk2xfWcP0/j+qrk2ZFAcBRxrMJxgf0YknHzSEGzG9ohaLrR1zTZZUxkPhVTy/TSVvQ4RhrdXONENd9rsvN2W51aHQ== X-Received: by 10.129.153.3 with SMTP id q3mr47371634ywg.231.1451335668983; Mon, 28 Dec 2015 12:47:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Mon, 28 Dec 2015 12:47:09 -0800 (PST) In-Reply-To: <20151228204103.17780804.52985.42662@ll.mit.edu> References: <20151228204103.17780804.52985.42662@ll.mit.edu> From: Eric Rescorla Date: Mon, 28 Dec 2015 15:47:09 -0500 Message-ID: To: "Blumenthal, Uri - 0553 - MITLL" Content-Type: multipart/alternative; boundary=94eb2c0bbfae0014100527fb6baa Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Mon, 28 Dec 2015 20:47:51 -0000 --94eb2c0bbfae0014100527fb6baa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To be clear, the concern that we are trying to alleviate is encrypting too much plaintext with the same key (see the discussion by Watson at the beginning of this thread). For that purpose, I'm not following why we need to introduce new randomness (draft-11 doesn't do so, but just cranks the KDF forward). It's possible I've misunderstood something, though, so happy to be corrected. -Ekr On Mon, Dec 28, 2015 at 3:40 PM, Blumenthal, Uri - 0553 - MITLL < uri@ll.mit.edu> wrote: > Off-hand, key update or re-key without new/fresh=E2=80=8E randomness soun= ds weird. > > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE netw= ork. > *From: *Eric Rescorla > *Sent: *Monday, December 28, 2015 15:37 > *To: *Florian Weimer > *Cc: *tls@ietf.org > *Subject: *Re: [TLS] Data volume limits > > > > On Mon, Dec 28, 2015 at 3:33 PM, Florian Weimer > wrote: > >> On 12/28/2015 09:11 PM, Eric Rescorla wrote: >> >> >> You still have the added complexity that during rekey, you need to >> >> temporarily switch from mere sending or receiving to at least >> >> half-duplex interaction. >> >> >> > >> > That's not intended. Indeed, you need to be able to handle the old key >> > in order to send/receive the KeyUpdate. Can you elaborate on your >> concern? >> >> Ah, so you want to keep the current mechanism and not inject fresh >> randomness? Isn't this fairly risky? > > > Can you explain the risk you are concerned about in more detail? > > -Ekr > > > > --94eb2c0bbfae0014100527fb6baa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To be clear, the concern that we are trying to alleviate i= s encrypting too much plaintext with the
same key (see the discussion b= y Watson at the beginning of this thread). For that purpose,
I= 9;m not following why we need to introduce new randomness (draft-11 doesn&#= 39;t do so,
but just cranks the KDF forward).

It's possible I've misunderstood something, though, so happy = to be corrected.

-Ekr


On Mon, Dec 28, 2015 at 3:40 PM, Blumenthal, Uri - 0553 - MITLL <uri@ll= .mit.edu> wrote:
= Off-hand, key update or re-key without new/fresh=E2=80=8E r= andomness sounds weird.
= =

= =
=
Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A01= 0=C2=A0smartphone=C2=A0on=C2=A0the=C2=A0Verizon=C2=A0Wireless=C2=A04G=C2=A0= LTE=C2=A0network.
= =
From: Eric Rescorla
Sent: Monday= , December 28, 2015 15:37
To: Florian Weimer
= Cc: tls@ietf.org<= /div>
Subject: Re: [TLS] Data volume limits



On Mon, Dec 28, 2015 at 3:33 PM, Florian Weimer = <fweimer@redhat.= com> wrote:
On 12/28/2015 09:11 PM, Eric Rescorla wrote:

>> You still have the added complexity that during rekey, you need to=
>> temporarily switch from mere sending or receiving to at least
>> half-duplex interaction.
>>
>
> That's not intended. Indeed, you need to be able to handle the old= key
> in order to send/receive the KeyUpdate. Can you elaborate on your conc= ern?

Ah, so you want to keep the current mechanism and not inject fresh randomness?=C2=A0 Isn't this fairly risky?

Can you explain the risk you are concerned about in more detail?

-Ekr




--94eb2c0bbfae0014100527fb6baa-- From nobody Mon Dec 28 12:51:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2701ACC86 for ; Mon, 28 Dec 2015 12:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 LQ2_3dpwfNUF for ; Mon, 28 Dec 2015 12:51:03 -0800 (PST) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 36B4F1ACC82 for ; Mon, 28 Dec 2015 12:51:02 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id tBSKp2Mo025017; Mon, 28 Dec 2015 15:51:02 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Eric Rescorla Thread-Topic: [TLS] Data volume limits Thread-Index: AdFBsXYBde9nh48KlkmRxpLGJ4HFmw== Date: Mon, 28 Dec 2015 20:51:01 +0000 Message-ID: <20151228205101.17780804.92503.42669@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============1557926193==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2015-12-28_13:2015-12-28,2015-12-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1511060000 definitions=main-1512280390 Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Mon, 28 Dec 2015 20:51:05 -0000 --===============1557926193== Content-Type: multipart/alternative; boundary="===============0454815585==" MIME-Version: 1.0 --===============0454815585== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 V2hlbiB0b28gbXVjaCBwbGFpbnRleHQgaGFzIGJlZW4gZW5jcnlwdGVkIHdpdGggdGhlIHNhbWUg a2V5LCB0aGUga2V5IG5lZWRzIHRvIGJlIGNoYW5nZWQuIFdoZW4gdGhlIGtleSBpcyBjaGFuZ2Vk LCB0aGUgY2hhbmdlIHByb2NlZHVyZSBzaG91bGQgaW52b2x2ZSBuZXcgcmFuZG9tbmVzcy7CoAoK V2hhdCdzIHRoZSBjb25mdXNpb24gaGVyZT8/PwoKU2VudMKgZnJvbcKgbXnCoEJsYWNrQmVycnnC oDEwwqBzbWFydHBob25lwqBvbsKgdGhlIFZlcml6b27CoFdpcmVsZXNzwqA0R8KgTFRFwqBuZXR3 b3JrLgpGcm9tOiBFcmljIFJlc2NvcmxhClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMjgsIDIwMTUg MTU6NDcKVG86IEJsdW1lbnRoYWwsIFVyaSAtIDA1NTMgLSBNSVRMTApDYzogRmxvcmlhbiBXZWlt ZXI7IHRsc0BpZXRmLm9yZwpTdWJqZWN0OiBSZTogW1RMU10gRGF0YSB2b2x1bWUgbGltaXRzCgpU byBiZSBjbGVhciwgdGhlIGNvbmNlcm4gdGhhdCB3ZSBhcmUgdHJ5aW5nIHRvIGFsbGV2aWF0ZSBp cyBlbmNyeXB0aW5nIHRvbyBtdWNoIHBsYWludGV4dCB3aXRoIHRoZQpzYW1lIGtleSAoc2VlIHRo ZSBkaXNjdXNzaW9uIGJ5IFdhdHNvbiBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoaXMgdGhyZWFkKS4g Rm9yIHRoYXQgcHVycG9zZSwKSSdtIG5vdCBmb2xsb3dpbmcgd2h5IHdlIG5lZWQgdG8gaW50cm9k dWNlIG5ldyByYW5kb21uZXNzIChkcmFmdC0xMSBkb2Vzbid0IGRvIHNvLApidXQganVzdCBjcmFu a3MgdGhlIEtERiBmb3J3YXJkKS4KCkl0J3MgcG9zc2libGUgSSd2ZSBtaXN1bmRlcnN0b29kIHNv bWV0aGluZywgdGhvdWdoLCBzbyBoYXBweSB0byBiZSBjb3JyZWN0ZWQuCgotRWtyCgoKCk9uIE1v biwgRGVjIDI4LCAyMDE1IGF0IDM6NDAgUE0sIEJsdW1lbnRoYWwsIFVyaSAtIDA1NTMgLSBNSVRM TCA8dXJpQGxsLm1pdC5lZHU+IHdyb3RlOgpPZmYtaGFuZCwga2V5IHVwZGF0ZSBvciByZS1rZXkg d2l0aG91dCBuZXcvZnJlc2jigI4gcmFuZG9tbmVzcyBzb3VuZHMgd2VpcmQuCgpTZW50wqBmcm9t wqBtecKgQmxhY2tCZXJyecKgMTDCoHNtYXJ0cGhvbmXCoG9uwqB0aGUgVmVyaXpvbsKgV2lyZWxl c3PCoDRHwqBMVEXCoG5ldHdvcmsuCkZyb206IEVyaWMgUmVzY29ybGEKU2VudDogTW9uZGF5LCBE ZWNlbWJlciAyOCwgMjAxNSAxNTozNwpUbzogRmxvcmlhbiBXZWltZXIKQ2M6IHRsc0BpZXRmLm9y ZwpTdWJqZWN0OiBSZTogW1RMU10gRGF0YSB2b2x1bWUgbGltaXRzCgoKCk9uIE1vbiwgRGVjIDI4 LCAyMDE1IGF0IDM6MzMgUE0sIEZsb3JpYW4gV2VpbWVyIDxmd2VpbWVyQHJlZGhhdC5jb20+IHdy b3RlOgpPbiAxMi8yOC8yMDE1IDA5OjExIFBNLCBFcmljIFJlc2NvcmxhIHdyb3RlOgoKPj4gWW91 IHN0aWxsIGhhdmUgdGhlIGFkZGVkIGNvbXBsZXhpdHkgdGhhdCBkdXJpbmcgcmVrZXksIHlvdSBu ZWVkIHRvCj4+IHRlbXBvcmFyaWx5IHN3aXRjaCBmcm9tIG1lcmUgc2VuZGluZyBvciByZWNlaXZp bmcgdG8gYXQgbGVhc3QKPj4gaGFsZi1kdXBsZXggaW50ZXJhY3Rpb24uCj4+Cj4KPiBUaGF0J3Mg bm90IGludGVuZGVkLiBJbmRlZWQsIHlvdSBuZWVkIHRvIGJlIGFibGUgdG8gaGFuZGxlIHRoZSBv bGQga2V5Cj4gaW4gb3JkZXIgdG8gc2VuZC9yZWNlaXZlIHRoZSBLZXlVcGRhdGUuIENhbiB5b3Ug ZWxhYm9yYXRlIG9uIHlvdXIgY29uY2Vybj8KCkFoLCBzbyB5b3Ugd2FudCB0byBrZWVwIHRoZSBj dXJyZW50IG1lY2hhbmlzbSBhbmQgbm90IGluamVjdCBmcmVzaApyYW5kb21uZXNzP8KgIElzbid0 IHRoaXMgZmFpcmx5IHJpc2t5PwoKQ2FuIHlvdSBleHBsYWluIHRoZSByaXNrIHlvdSBhcmUgY29u Y2VybmVkIGFib3V0IGluIG1vcmUgZGV0YWlsPwoKLUVrcgoKCgoKCg== --===============0454815585== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable =
When too much p= laintext has been encrypted with the same key, the key needs to be changed.= When the key is changed, the change procedure should involve new randomnes= s. 

What's the confusion here???
= =

= =
<= /div>
Sent from my BlackBerry 10 smartphone = ;on the Verizon Wireless 4G LTE network. = =
=
<= div>From: Eric Rescorla
Sent: Monday, December 28, = 2015 15:47
To: Blumenthal, Uri - 0553 - MITLL
Cc: Florian Weimer; tls@ietf.org
Subject: Re: [TLS] D= ata volume limits

To be clear, the concern that we are trying to alleviate i= s encrypting too much plaintext with the
same key (see the discussion by Watson at the beginning of this thread= ). For that purpose,
I'm not following why we need to introduce new randomness (draft-11 do= esn't do so,
but just cranks the KDF forward).

It's possible I've misunderstood something, though, so happy to be cor= rected.

-Ekr



On Mon, Dec 28, 2015 at 3:40 PM, Blumenthal, Uri= - 0553 - MITLL <uri@ll.mit.edu&= gt; wrote:
Sent from my BlackBerry 10 smartphone on = ;the Verizon Wireless 4G LTE network.
From: Eric Rescorla
Sent: Monday, December 28, 2015 15:37
To: Florian Weimer
Subject: Re: [TLS] Data volume limits



On Mon, Dec 28, 2015 at 3:33 PM, Florian Weimer = <fweimer@redhat.com>= wrote:
On 12/28/2015 09:11 PM, Eric Rescorla wrote:

>> You still have the added complexity that during rekey, you need to=
>> temporarily switch from mere sending or receiving to at least
>> half-duplex interaction.
>>
>
> That's not intended. Indeed, you need to be able to handle the old key=
> in order to send/receive the KeyUpdate. Can you elaborate on your conc= ern?

Ah, so you want to keep the current mechanism and not inject fresh randomness?  Isn't this fairly risky?

Can you explain the risk you are concerned about in more detail?

-Ekr





--===============0454815585==-- --===============1557926193== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKTM8n7QAAAABB0TANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE1MDYwNTE4MTY0NFoXDTE2MDYwNDE4MTY0NFowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDQ 0ZYk84x0NrbLSMf9w+9rvO8Z3d5dfpynEt9it4HkQ3Fht5wpD1DOICbdPmcuoNGv73LUI6oRn7XT CnAFOeW9dGZetOUBIL44l0BoMYlUOvqOhtXUIoxm6PNbnDsYW3HpNuiskGO+jjH5CrvSFsZ//GHA dMGsQpRNBU7ZHCoOZF7+rv9RUh5pN5OgKumv9p24nWtGHNR1AHHDjB50Df9/1DVGhpe6aqf5DBhe f+1rf/dgAhjFSzrj3lTgNuczkZcB9Xs6fktq1jRCuwCdVTXQ/xgM5I3FHnVP73QEccOFR9qfdEVA 5IT7jo/7hMIvOBMWUJGOP7BpYXJd4VKj8CxLAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUr3pideNu 8mmOhHY8C2sJnlo/HVAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAKVaDwP2SaWtXtIINTrHpvDXC9dslWAv Tfg3TmHrQMtlKM6GQqkgIzF4WMZgM64RyUOqEnXrDcD7a3GPrcf8zDjRnsTiYaGkzhEUb/do5igL Al5x+FwAvhwvEuLJwHpAk0sfbxfX4lxY1S1YUngS+5PXGJbbFaNPAOefDG8jGgaM4TJ1weWlLT8F /MJudL6L6azCfOWQZhxpnT037XWGPeUfuqNnmwkwwlrCQB2QYgLQJtlUZQPqnb8Y2hd6OfhE7qvv /fcvX7i+Q4UKh3xGlMN2QHoX0Sk9sxxc4vgJnKk7MhaufGtOuNJLZlSfzCQRGd9Zprq9M+ROXuwN u72bKQkwggTqMIID0qADAgECAgpMzyftAAAAAEHRMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTUwNjA1MTgxNjQ0WhcNMTYwNjA0MTgxNjQ0WjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANDRliTzjHQ2tstIx/3D72u87xnd3l1+nKcS32K3geRDcWG3nCkPUM4gJt0+Zy6g0a/v ctQjqhGftdMKcAU55b10Zl605QEgvjiXQGgxiVQ6+o6G1dQijGbo81ucOxhbcek26KyQY76OMfkK u9IWxn/8YcB0waxClE0FTtkcKg5kXv6u/1FSHmk3k6Aq6a/2nbida0Yc1HUAccOMHnQN/3/UNUaG l7pqp/kMGF5/7Wt/92ACGMVLOuPeVOA25zORlwH1ezp+S2rWNEK7AJ1VNdD/GAzkjcUedU/vdARx w4VH2p90RUDkhPuOj/uEwi84ExZQkY4/sGlhcl3hUqPwLEsCAwEAAaOCAbIwggGuMB0GA1UdDgQW BBSvemJ1427yaY6EdjwLawmeWj8dUDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEApVoPA/ZJpa1e0gg1Osem 8NcL12yVYC9N+DdOYetAy2UozoZCqSAjMXhYxmAzrhHJQ6oSdesNwPtrcY+tx/zMONGexOJhoaTO ERRv92jmKAsCXnH4XAC+HC8S4snAekCTSx9vF9fiXFjVLVhSeBL7k9cYltsVo08A558MbyMaBozh MnXB5aUtPwX8wm50vovprMJ85ZBmHGmdPTftdYY95R+6o2ebCTDCWsJAHZBiAtAm2VRlA+qdvxja F3o5+ETuq+/99y9fuL5DhQqHfEaUw3ZAehfRKT2zHFzi+AmcqTsyFq58a0640ktmVJ/MJBEZ31mm ur0z5E5e7A27vZspCTCCBO0wggPVoAMCAQICCihwejIAAAAALQcwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNTAxMjMxNzQ5MjlaFw0xNjAxMjMxNzQ5MjlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxfkXLPYTTuYb5RNGHpbanlxlFtbt0VTBuP9moOidhYHLDicTmcv5vuxX mHwqN12Kzasev9yGZg0mJZ9yZ8cz4qJw3GytkyfcQDqFpa1MpAIYFJfjwjvGoQ1eWHNLZjM3+TFw a7Lm9J1MiXg5MTlGNiHefA9VFc814fSr43PmQnAURaFYgIJ+zM557ryvGOZuy6K9aC1ksTTVMqff IAuBKXRy5wPMj9Vqpja9MfmLLIyYBIiH2RasfBr79jqrR2hRh4e2OvljliGVCzGgHPSSRKvHLZ7P ZhiEZXX9iTBXDbGoUCQ4YFLKZj+nNVs/Tq1MbIMJxkOX3iKvXP+GGWBGfwIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFEdIXm5OIutOt2J6RBFV8kFMn0hTMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQA4puc4 02/4d3mv+ugzTOsEpotU4vRdn9vwK3tmu2vRPyD135Xod/ZVRu7k2p3hCTEh8w5bZAeZOg2DL/7d vJ7UJtoyyPWnTMHHA5SkkdriA7IgO46HYk8W6i/2kYvlguMm1loV7s0m5DHrGsreUACqbiiwK+53 sH2WlsfMz51lNZ1mQWyUe3CyoFE2hIkLvzZQliBSSAvckYc3vikeNbyGvu54kJ1ADY6GAgrt9mfM YMYSuJEK+bXlFVDQ6Ao9Nse/NRhX8ApJ8abFhJveTljNYmlyghifHIoqLpRM5LGVKyB3SJiEmkFV fl3Zm3Hdzh+svHzZdZmXV5/LMTSXPv4NMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgpMzyftAAAAAEHRMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTIyODIwNTEwMFowLwYJKoZIhvcNAQkEMSIEIHAwfdB3xAbA MI9LL24XMRgvGYi/LM/2mMrytwPJ8h0JMAsGCSqGSIb3DQEBCwSCAQAfwvGJPdAR9x5xu0N4j/9e 9HO7UvqnmhY4rKRZhN32XOUbSy9Le2NkNoG/6SWKI3h5CwWRDyK943K0X4+ltnEqDiWuVy7xXNPP yMWynyHcu3kRLzA+O16rfXWYXu6ZvlGPseVTJgyqUJGSr9rV2dVIf+2W/8eHWMUjFCITklkew9Tf Y689YbXpcMqRLsVix4/fajl9lv/z010PB8YbgvO617/ajPj+3LzWCVhBnCGT3cn3bwJ2JavlM4fl AF6kZ7J406iZZkuLcumFQbaxY0bRp2nx5oWj6lpGNZWJL1vWbF4J9HL51dws3mKCahvz1QOmZ6N3 S5yB+Yxnhn1wGibMAAAAAAAA --===============1557926193==-- From nobody Mon Dec 28 12:56:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3DC1ACC92 for ; Mon, 28 Dec 2015 12:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 SWBZgBExpNNL for ; Mon, 28 Dec 2015 12:56:13 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id DF7A71ACC8F for ; Mon, 28 Dec 2015 12:56:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 7549821E; Mon, 28 Dec 2015 22:56:11 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id KgXenPIkFJrW; Mon, 28 Dec 2015 22:56:11 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id D34C91EE; Mon, 28 Dec 2015 22:56:10 +0200 (EET) Date: Mon, 28 Dec 2015 22:56:10 +0200 From: Ilari Liusvaara To: "Blumenthal, Uri - 0553 - MITLL" Message-ID: <20151228205610.GA5798@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151228205101.17780804.92503.42669@ll.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20151228205101.17780804.92503.42669@ll.mit.edu> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Mon, 28 Dec 2015 20:56:14 -0000 On Mon, Dec 28, 2015 at 08:51:01PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > When too much plaintext has been encrypted with the same key, the > key needs to be changed. When the key is changed, the change > procedure should involve new randomness.  > > What's the confusion here??? OTOH, you can't drop an attacker knowing older key without doing new key exchange. Introducing new randomness would complicate the rekeying _greatly_ as now you need to handle synchronization (which also causes nasty problems at application layer). So one wouldn't want to do that without really good reason. Breaking the symmetry between rekeyings (including the rekey counter in key derivation) might be feasible tho. -Ilari From nobody Mon Dec 28 13:09:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D4F1ACCEA for ; Mon, 28 Dec 2015 13:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ZGfkpYSoGBwb for ; Mon, 28 Dec 2015 13:09:45 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 293601ACCE9 for ; Mon, 28 Dec 2015 13:09:44 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E261B4EC21; Mon, 28 Dec 2015 21:09:43 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id CB28A4EB73; Mon, 28 Dec 2015 21:09:43 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1451336983; bh=aVt8tUo5lrM3T6uUf9zODwy5aY2KwVPSD/IYc72L84M=; l=412; h=From:To:CC:Date:References:In-Reply-To:From; b=od5ASBao+qkd0fP2fFdzyAcNKBTiHI96jtaCV5Rtk3v3g4SW/r2cinp9rEXxj8W78 WR5eFTGLyPwNDT49b+CppTz4moUcd5RisIxHdwCTxF0kcyjqw7il1SqA7plFYl0Uvi Iia3fkK2SuUFHebz4iGFYE9O55CvPERrmA6v2PUQ= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id C80082029; Mon, 28 Dec 2015 21:09:43 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 28 Dec 2015 16:09:43 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Mon, 28 Dec 2015 16:09:43 -0500 From: "Salz, Rich" To: "Blumenthal, Uri - 0553 - MITLL" , Eric Rescorla Thread-Topic: [TLS] Data volume limits Thread-Index: AdFBsXYBb98SwWA8XEO5okq0NNVIjgAAlwZw Date: Mon, 28 Dec 2015 21:09:42 +0000 Message-ID: <054fc579d2fa41dfa03ad8366bb3c02b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20151228205101.17780804.92503.42669@ll.mit.edu> In-Reply-To: <20151228205101.17780804.92503.42669@ll.mit.edu> 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: [172.19.32.109] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Mon, 28 Dec 2015 21:09:47 -0000 PiBXaGVuIHRoZSBrZXkgaXMgY2hhbmdlZCwgdGhlIGNoYW5nZSBwcm9jZWR1cmUgc2hvdWxkIGlu dm9sdmUgbmV3IHJhbmRvbW5lc3MuwqANCg0KSSBkb24ndCB0aGluayB0aGlzIGlzIG5lY2Vzc2Fy eSwgYW5kIEkgZG9uJ3QgdGhpbmsgdGhlIGNvbW1vbiBjcnlwdG8gZXhwZXJ0aXNlIGFncmVlcyB3 aXRoIHlvdSwgZWl0aGVyLiBCdXQgSSBhbSBub3QgYSBjcnlwdG9ncmFwaGVyLCBtYXliZSBvbmUg b2YgdGhlIG9uZXMgb24gdGhpcyBsaXN0IGNhbiBjaGltZSBpbi4NCg0KIkNyYW5rIHRoZSBLREYi IHN1ZmZpY2VzLg0KIA0K From nobody Mon Dec 28 13:17:12 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C461ACCFA for ; Mon, 28 Dec 2015 13:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 uQtc9wffjcoN for ; Mon, 28 Dec 2015 13:17:08 -0800 (PST) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 75D951ACCF8 for ; Mon, 28 Dec 2015 13:17:08 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id tBSLH5gP031587; Mon, 28 Dec 2015 16:17:05 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: "Salz, Rich" , Eric Rescorla Thread-Topic: [TLS] Data volume limits Thread-Index: AdFBtRnBde9nh48KlkmRxpLGJ4HFmw== Date: Mon, 28 Dec 2015 21:17:04 +0000 Message-ID: <20151228211713.17780804.97613.42679@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============0794908206==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2015-12-28_13:2015-12-28,2015-12-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1511060000 definitions=main-1512280400 Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Mon, 28 Dec 2015 21:17:10 -0000 --===============0794908206== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable "Cranking the KDF" suffices for providing "subkeys" that are cryptographica= lly intractable, which should address the concern of "too much plaintext un= der the same key". That's less than what I'd consider a "full re-key". =E2= =80=8EAnd even then "cranking the KDF" with something newly-random isn't a = bad idea at all. I don't think common crypto expertise would disagree. Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the Verizon=C2=A0Wireless=C2=A04G=C2=A0LTE=C2=A0network. =C2=A0 Original Message =C2=A0 From: Salz, Rich Sent: Monday, December 28, 2015 16:09 To: Blumenthal, Uri - 0553 - MITLL; Eric Rescorla Cc: Florian Weimer; tls@ietf.org Subject: RE: [TLS] Data volume limits > When the key is changed, the change procedure should involve new randomne= ss.=C2=A0 =E2=80=8E I don't think this is necessary, and I don't think the common crypto expert= ise agrees with you, either. But I am not a cryptographer, maybe one of the= ones on this list can chime in. "Crank the KDF" suffices. --===============0794908206== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKTM8n7QAAAABB0TANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE1MDYwNTE4MTY0NFoXDTE2MDYwNDE4MTY0NFowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDQ 0ZYk84x0NrbLSMf9w+9rvO8Z3d5dfpynEt9it4HkQ3Fht5wpD1DOICbdPmcuoNGv73LUI6oRn7XT CnAFOeW9dGZetOUBIL44l0BoMYlUOvqOhtXUIoxm6PNbnDsYW3HpNuiskGO+jjH5CrvSFsZ//GHA dMGsQpRNBU7ZHCoOZF7+rv9RUh5pN5OgKumv9p24nWtGHNR1AHHDjB50Df9/1DVGhpe6aqf5DBhe f+1rf/dgAhjFSzrj3lTgNuczkZcB9Xs6fktq1jRCuwCdVTXQ/xgM5I3FHnVP73QEccOFR9qfdEVA 5IT7jo/7hMIvOBMWUJGOP7BpYXJd4VKj8CxLAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUr3pideNu 8mmOhHY8C2sJnlo/HVAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAKVaDwP2SaWtXtIINTrHpvDXC9dslWAv Tfg3TmHrQMtlKM6GQqkgIzF4WMZgM64RyUOqEnXrDcD7a3GPrcf8zDjRnsTiYaGkzhEUb/do5igL Al5x+FwAvhwvEuLJwHpAk0sfbxfX4lxY1S1YUngS+5PXGJbbFaNPAOefDG8jGgaM4TJ1weWlLT8F /MJudL6L6azCfOWQZhxpnT037XWGPeUfuqNnmwkwwlrCQB2QYgLQJtlUZQPqnb8Y2hd6OfhE7qvv /fcvX7i+Q4UKh3xGlMN2QHoX0Sk9sxxc4vgJnKk7MhaufGtOuNJLZlSfzCQRGd9Zprq9M+ROXuwN u72bKQkwggTqMIID0qADAgECAgpMzyftAAAAAEHRMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTUwNjA1MTgxNjQ0WhcNMTYwNjA0MTgxNjQ0WjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANDRliTzjHQ2tstIx/3D72u87xnd3l1+nKcS32K3geRDcWG3nCkPUM4gJt0+Zy6g0a/v ctQjqhGftdMKcAU55b10Zl605QEgvjiXQGgxiVQ6+o6G1dQijGbo81ucOxhbcek26KyQY76OMfkK u9IWxn/8YcB0waxClE0FTtkcKg5kXv6u/1FSHmk3k6Aq6a/2nbida0Yc1HUAccOMHnQN/3/UNUaG l7pqp/kMGF5/7Wt/92ACGMVLOuPeVOA25zORlwH1ezp+S2rWNEK7AJ1VNdD/GAzkjcUedU/vdARx w4VH2p90RUDkhPuOj/uEwi84ExZQkY4/sGlhcl3hUqPwLEsCAwEAAaOCAbIwggGuMB0GA1UdDgQW BBSvemJ1427yaY6EdjwLawmeWj8dUDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEApVoPA/ZJpa1e0gg1Osem 8NcL12yVYC9N+DdOYetAy2UozoZCqSAjMXhYxmAzrhHJQ6oSdesNwPtrcY+tx/zMONGexOJhoaTO ERRv92jmKAsCXnH4XAC+HC8S4snAekCTSx9vF9fiXFjVLVhSeBL7k9cYltsVo08A558MbyMaBozh MnXB5aUtPwX8wm50vovprMJ85ZBmHGmdPTftdYY95R+6o2ebCTDCWsJAHZBiAtAm2VRlA+qdvxja F3o5+ETuq+/99y9fuL5DhQqHfEaUw3ZAehfRKT2zHFzi+AmcqTsyFq58a0640ktmVJ/MJBEZ31mm ur0z5E5e7A27vZspCTCCBO0wggPVoAMCAQICCihwejIAAAAALQcwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNTAxMjMxNzQ5MjlaFw0xNjAxMjMxNzQ5MjlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxfkXLPYTTuYb5RNGHpbanlxlFtbt0VTBuP9moOidhYHLDicTmcv5vuxX mHwqN12Kzasev9yGZg0mJZ9yZ8cz4qJw3GytkyfcQDqFpa1MpAIYFJfjwjvGoQ1eWHNLZjM3+TFw a7Lm9J1MiXg5MTlGNiHefA9VFc814fSr43PmQnAURaFYgIJ+zM557ryvGOZuy6K9aC1ksTTVMqff IAuBKXRy5wPMj9Vqpja9MfmLLIyYBIiH2RasfBr79jqrR2hRh4e2OvljliGVCzGgHPSSRKvHLZ7P ZhiEZXX9iTBXDbGoUCQ4YFLKZj+nNVs/Tq1MbIMJxkOX3iKvXP+GGWBGfwIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFEdIXm5OIutOt2J6RBFV8kFMn0hTMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQA4puc4 02/4d3mv+ugzTOsEpotU4vRdn9vwK3tmu2vRPyD135Xod/ZVRu7k2p3hCTEh8w5bZAeZOg2DL/7d vJ7UJtoyyPWnTMHHA5SkkdriA7IgO46HYk8W6i/2kYvlguMm1loV7s0m5DHrGsreUACqbiiwK+53 sH2WlsfMz51lNZ1mQWyUe3CyoFE2hIkLvzZQliBSSAvckYc3vikeNbyGvu54kJ1ADY6GAgrt9mfM YMYSuJEK+bXlFVDQ6Ao9Nse/NRhX8ApJ8abFhJveTljNYmlyghifHIoqLpRM5LGVKyB3SJiEmkFV fl3Zm3Hdzh+svHzZdZmXV5/LMTSXPv4NMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgpMzyftAAAAAEHRMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTIyODIxMTcxMFowLwYJKoZIhvcNAQkEMSIEIIs2ryRR1Bg/ N54b8sWbOlZb319KD0uWEK5nKJdYjgSIMAsGCSqGSIb3DQEBCwSCAQBU/+IwKD3VJhkiwYO2tz9L nxcRe0egOndlpLwCmmYO7KqxUedVsmBaUN8mlCMRu+y0Ab/kqbEvWO6qdddds7SG3KW2eh0WhGCT /GAJ1BSnn/AhOgbx71l86hh5e5+PF6PmaivfbNZGdi7tfhRUdliNC7kvKwnebq/1zVXRqv5SMeoG gkIrNslEHDYXOSunRRd1hAlUWFw8rc2cifyPZb3Kl8HrctM3hB7FbQRQsZhvAcYN7mi6mxr72+VJ JSIt0pdtP0Zw6Cv02QWR/Emm9Q5OKGCrraqKNJY/9bXVn+FIeSejlHfMVgiFVYThO1zu2CiLiBJA SfZBHKZUiJ44fhmpAAAAAAAA --===============0794908206==-- From nobody Mon Dec 28 13:49:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2041ACD2E for ; Mon, 28 Dec 2015 13:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, T_RP_MATCHES_RCVD=-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 Rcl6_b-wDLmD for ; Mon, 28 Dec 2015 13:49:18 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2F64F1ACD2D for ; Mon, 28 Dec 2015 13:49:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id CF9E81A4; Mon, 28 Dec 2015 23:49:16 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id cHHGm6wSQNy7; Mon, 28 Dec 2015 23:49:16 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 51FAF230D; Mon, 28 Dec 2015 23:49:16 +0200 (EET) Date: Mon, 28 Dec 2015 23:49:15 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20151228214915.GB5798@LK-Perkele-V2.elisa-laajakaista.fi> References: <201512241748.25385.davemgarrett@gmail.com> <201512270208.11253.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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: Mon, 28 Dec 2015 21:49:20 -0000 On Mon, Dec 28, 2015 at 06:46:02AM -0500, Eric Rescorla wrote: > On Sun, Dec 27, 2015 at 11:55 PM, Christian Huitema > wrote: > > > For DTLS, we have to consider the packet injection threat. It is fairly > > easy to send some random bytes with a fake source to a UDP destination. > > Such attacks should not cause the DTLS association to fail! The normal > > behavior ought to be to just ignore UDP packets that fail to decrypt. This > > would cause 0-RTT rejects to just result in dropped packets. Can we ensure > > that the handshake protocol is robust against that? > > > > We obviously need to distinguish here between handshake and application > data messages, because DTLS is intended to allow loss of application data > messages. > > WRT handshake messages, as I indicated before, I believe that there is > enough information in the handshake messages to prevent removal. > Namely: > > 1. The ClientHello contains an indication that 0-RTT handshake messages > are coming. > 2. The Client's 0-RTT Finished contains a MAC of all the Client's > 0-RTT messages. > 3. The Server's Finished contains a MAC of the ClientHello. > > Thus, provided that the client and server in fact share a configuration > (which, again, is in the ClientHello) then the server knows at the time > of receiving the first-flight Finished that he has (or has not) received > all the client's 0-RTT Handshake messages. [0]. Also, maybe a stupid question: While the 0-RTT handshake parts are obviously reliably transmitted, is the same true for the 0-RTT data part? That is, is the server allowed to ACK the flight after having received ClientHello/Certificate/CertificateVerify/Finished; and deal with any 0-RTT data messages should they arrive (these are not necressarily retransmitted if lost)? Or if the context does not support early auth, just ACK immediately after ClientHello. It occurs to me that data messages in DTLS 1.2 lack the fields needed for automatic retransmission. > The more interesting question, however, is what drives the DTLS state > machine forward to ensure progress in the face of innocuous loss. > The basic DTLS design is that the receipt of the first message of the > peer's next flight indicates receipt of the entire flight. In this case, > then, the receipt of the ServerHello would indicate receipt of the > Client's 0-RTT Finished. However, this would place a requirement > that the server not *send* the ServerHello until that point, which we've > left open in WIP-11 by not hashing in the 0-RTT plaintext. I think that would be fairly easy way to deal with it (not saying that simpler ways don't exist). Also, on topic of DTLS 1.3... It occurs to me that naively doing it would leave it open to "fragementation attacks" a'la IPv6. Basically, it occurs to me that ClientHello messages SHOULD NOT be fragmented (at TLS level, SCTP(?) or IP level fragmentation is another kettle of fish) and if it is fragmented, the Cookie extension MUST be in the first fragment. The 0-RTT messages aren't so bad as those can just be dropped if server does not want to accept right now. Also, there's question of how to handle HelloVerifyReqest (one can't just downgrade to DTLS 1.2!). One way: - If it was in reply to ClientHello with EarlyData extension (at least with early auth?), treat it as fatal protocol_version Alert. TLS 1.2 can't handle early data. - If it was in reply to ClientHello without EarlyData extension, write the cookie into the header cookie field (not extension cookie field) and resend. This counts as a retry. -Ilari From nobody Mon Dec 28 16:00:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F401ACDFD for ; Mon, 28 Dec 2015 16:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] 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 2YOrVWq8N4gm for ; Mon, 28 Dec 2015 16:00:28 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70CA71ACDFB for ; Mon, 28 Dec 2015 16:00:28 -0800 (PST) Received: by mail-yk0-x236.google.com with SMTP id k129so94438969yke.0 for ; Mon, 28 Dec 2015 16:00:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jgOicE2WX/w+Me1lAPah/W3LmhQ9xbfoEoOJEH35kH8=; b=K3hsCXVywPeuCzBCHICTXhL6fvKOMnaiK3AG+FGPlyjm0H+7QBFcnSrPjJVMjcZuSi Ch55j10Fh0Vu8VafKFCMFZHzD+TA9RQkxeDwW34O25Nl3VhrP1DtZzUpDqwyyX4bX9Yx ksS4J7eMvOYAKHgxPPtTTp/fLR6F4E3joWZURB/NKZ4hRNA0Mw/BeQhnIwKv9J49A0L9 NQelpEOC7fkAKgY1YKEvzQEFMaChqmy6m4wUijT6GoM5tqJIvSUezCTChP4huR9ycyXg c8k9Rs5Nn4ObLbXayLSh7ur2N8Y9+Y8H1yxz+yrcbX0YkDvBGEOEKaZy5ZsRTanRrfYK iFSA== 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=jgOicE2WX/w+Me1lAPah/W3LmhQ9xbfoEoOJEH35kH8=; b=L8kXholBl+wCUCsOnniPIr/phdjbBZPrgn5ruoenkLSxwUqKBLIZmJ2qhth9JBy30N FmMkP/hZ0/Ft35hH6PH9ORcy+yk3oOJD4xv0qAzr3SmpvOOwgCu1fTMP24wDDNR4l7h5 amcP9Ta6dpAUHzWcQDTUQDCOHsXjAUigKXgp/7wiZMcTmrfVjhyQjsmSY2EtyyfWObUA TKKXhm68+yPy1on6Z3U93lm+8bUgT7RNLsXe65fyhCSruOEFqHLwamsbD1iU/+eAFJvW t8P1WGM7f32Qv3naxGsus4bhT8ht9DSVNPCvoplGAx4AQbRXudL6Nnwr0yzXdrxEShwN mlig== X-Gm-Message-State: ALoCoQntnICQlXnLtJmNCLZ7g6XOtdruNK4eMgQLRy7zuyiLAu2F7vRceM0XVA3JfL5mjOpTLdueujQEvrE8dWf1+8VTOt6k2g== X-Received: by 10.129.148.3 with SMTP id l3mr42451962ywg.155.1451347227657; Mon, 28 Dec 2015 16:00:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Mon, 28 Dec 2015 15:59:48 -0800 (PST) In-Reply-To: <20151228214915.GB5798@LK-Perkele-V2.elisa-laajakaista.fi> References: <201512241748.25385.davemgarrett@gmail.com> <201512270208.11253.davemgarrett@gmail.com> <20151228214915.GB5798@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Mon, 28 Dec 2015 18:59:48 -0500 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c07c8bcf379e00527fe1b30 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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, 29 Dec 2015 00:00:30 -0000 --94eb2c07c8bcf379e00527fe1b30 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 28, 2015 at 4:49 PM, Ilari Liusvaara wrote: > On Mon, Dec 28, 2015 at 06:46:02AM -0500, Eric Rescorla wrote: > > On Sun, Dec 27, 2015 at 11:55 PM, Christian Huitema < > huitema@microsoft.com> > > wrote: > > > > > For DTLS, we have to consider the packet injection threat. It is fairly > > > easy to send some random bytes with a fake source to a UDP destination. > > > Such attacks should not cause the DTLS association to fail! The normal > > > behavior ought to be to just ignore UDP packets that fail to decrypt. > This > > > would cause 0-RTT rejects to just result in dropped packets. Can we > ensure > > > that the handshake protocol is robust against that? > > > > > > > We obviously need to distinguish here between handshake and application > > data messages, because DTLS is intended to allow loss of application data > > messages. > > > > WRT handshake messages, as I indicated before, I believe that there is > > enough information in the handshake messages to prevent removal. > > Namely: > > > > 1. The ClientHello contains an indication that 0-RTT handshake messages > > are coming. > > 2. The Client's 0-RTT Finished contains a MAC of all the Client's > > 0-RTT messages. > > 3. The Server's Finished contains a MAC of the ClientHello. > > > > Thus, provided that the client and server in fact share a configuration > > (which, again, is in the ClientHello) then the server knows at the time > > of receiving the first-flight Finished that he has (or has not) received > > all the client's 0-RTT Handshake messages. [0]. > > Also, maybe a stupid question: > > While the 0-RTT handshake parts are obviously reliably transmitted, is > the same true for the 0-RTT data part? > No, nor for any DTLS data. The assumption is that this is handled at the layer above. That is, is the server allowed to ACK the flight after having received > ClientHello/Certificate/CertificateVerify/Finished; and deal with any > 0-RTT data messages should they arrive (these are not necressarily > retransmitted if lost)? > I would anticipate that this is the correct behavior and in fact this seems like the right behavior for TLS as well, since part of the point of 0-RTT data is to stream it ASAP. Note that there is no explicit ACK, though. Or if the context does not support early auth, just ACK immediately > after ClientHello. Yes, this is currently technicaly possible. It occurs to me that data messages in DTLS 1.2 lack the fields needed > for automatic retransmission. > > > The more interesting question, however, is what drives the DTLS state > > machine forward to ensure progress in the face of innocuous loss. > > The basic DTLS design is that the receipt of the first message of the > > peer's next flight indicates receipt of the entire flight. In this case, > > then, the receipt of the ServerHello would indicate receipt of the > > Client's 0-RTT Finished. However, this would place a requirement > > that the server not *send* the ServerHello until that point, which we've > > left open in WIP-11 by not hashing in the 0-RTT plaintext. > > I think that would be fairly easy way to deal with it (not saying that > simpler ways don't exist). > > > Also, on topic of DTLS 1.3... It occurs to me that naively doing it > would leave it open to "fragementation attacks" a'la IPv6. > > Basically, it occurs to me that ClientHello messages SHOULD NOT be > fragmented (at TLS level, SCTP(?) or IP level fragmentation is another > kettle of fish) and if it is fragmented, the Cookie extension MUST be > in the first fragment. > Sorry, I'm not sure I am processing this. Can you explain in more detail. Also, there's question of how to handle HelloVerifyReqest (one can't > just downgrade to DTLS 1.2!). One way: > > - If it was in reply to ClientHello with EarlyData extension (at least > with early auth?), treat it as fatal protocol_version Alert. TLS 1.2 > can't handle early data. > - If it was in reply to ClientHello without EarlyData extension, write > the cookie into the header cookie field (not extension cookie field) > and resend. This counts as a retry. Yes, this seems like the right answer. I.e., You only do HVR in TLS 1.2 and as we have discussed previously, once you have sent a ServerConfig, you have to continue to be able to do TLS 1.3, even if you forget the config. Best, -Ekr --94eb2c07c8bcf379e00527fe1b30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 28, 2015 at 4:49 PM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
O= n Mon, Dec 28, 2015 at 06:46:02AM -0500, Eric Rescorla wrote:
> On Sun, Dec 27, 2015 at 11:55 PM, Christian Huitema <huitema@microsoft.com><= br> > wrote:
>
> > For DTLS, we have to consider the packet injection t= hreat. It is fairly
> > easy to send some random bytes with a fake source to a UDP destin= ation.
> > Such attacks should not cause the DTLS association to fail! The n= ormal
> > behavior ought to be to just ignore UDP packets that fail to decr= ypt. This
> > would cause 0-RTT rejects to just result in dropped packets. Can = we ensure
> > that the handshake protocol is robust against that?
> >
>
> We obviously need to distinguish here between handshake and applicatio= n
> data messages, because DTLS is intended to allow loss of application d= ata
> messages.
>
> WRT handshake messages, as I indicated before, I believe that there is=
> enough information in the handshake messages to prevent removal.
> Namely:
>
> 1. The ClientHello contains an indication that 0-RTT handshake message= s
> are coming.
> 2. The Client's 0-RTT Finished contains a MAC of all the Client= 9;s
> 0-RTT messages.
> 3. The Server's Finished contains a MAC of the ClientHello.
>
> Thus, provided that the client and server in fact share a configuratio= n
> (which, again, is in the ClientHello) then the server knows at the tim= e
> of receiving the first-flight Finished that he has (or has not) receiv= ed
> all the client's 0-RTT Handshake messages. [0].

Also, maybe a stupid question:

While the 0-RTT handshake parts are obviously reliably transmitted, is
the same true for the 0-RTT data part?

= No, nor for any DTLS data. The assumption is that this is handled at the
layer above.


That is, is the server allowed to ACK the flight after having received
ClientHello/Certificate/CertificateVerify/Finished; and deal with any
0-RTT data messages should they arrive (these are not necressarily
retransmitted if lost)?

I would anticip= ate that this is the correct behavior and in fact this seems
= like the right behavior for TLS as well, since part of the point of 0-RTT
data is to stream it ASAP. Note that there is no explicit ACK, tho= ugh.


Or if the context does not support early auth, just ACK immediately
after ClientHello.

Yes, this is currently t= echnicaly possible.

It occurs to me that data messages in DTLS 1.2 lack the fields needed
for automatic retransmission.

> The more interesting question, however, is what drives the DTLS state<= br> > machine forward to ensure progress in the face of innocuous loss.
> The basic DTLS design is that the receipt of the first message of the<= br> > peer's next flight indicates receipt of the entire flight. In this= case,
> then, the receipt of the ServerHello would indicate receipt of the
> Client's 0-RTT Finished. However, this would place a requirement > that the server not *send* the ServerHello until that point, which we&= #39;ve
> left open in WIP-11 by not hashing in the 0-RTT plaintext.

I think that would be fairly easy way to deal with it (not saying th= at
simpler ways don't exist).


Also, on topic of DTLS 1.3... It occurs to me that naively doing it
would leave it open to "fragementation attacks" a'la IPv6.
Basically, it occurs to me that ClientHello messages SHOULD NOT be
fragmented (at TLS level, SCTP(?) or IP level fragmentation is another
kettle of fish) and if it is fragmented, the Cookie extension MUST be
in the first fragment.

Sorry, I'm n= ot sure I am processing this. Can you explain in more detail.

Also, there's question of how to handle HelloVerifyReqest (one can'= t
just downgrade to DTLS 1.2!). One way:

- If it was in reply to ClientHello with EarlyData extension (at least
=C2=A0 with early auth?), treat it as fatal protocol_version Alert. TLS 1.2=
=C2=A0 can't handle early data.
- If it was in reply to ClientHello without EarlyData extension, write
=C2=A0 the cookie into the header cookie field (not extension cookie field)=
=C2=A0 and resend. This counts as a retry.

= Yes, this seems like the right answer. I.e., You only do HVR in TLS 1.2
and as we have discussed previously, once you have sent a ServerConf= ig,
you have to continue to be able to do TLS 1.3, even if you fo= rget the config.

Best,
-Ekr


--94eb2c07c8bcf379e00527fe1b30-- From nobody Mon Dec 28 17:28:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA111ACE77 for ; Mon, 28 Dec 2015 17:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 sCFDUAaJT6YV for ; Mon, 28 Dec 2015 17:28:12 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0747.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:747]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F541ACE73 for ; Mon, 28 Dec 2015 17:28:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vEWiR+ACzo0JrE9fLEx3m7O/yaaB6QWTax+B0Fda2Eo=; b=UGWQiGKX3fg3Ih7Z1uo2txkvHme2U7XlQbHM+BwcEn4J+GKq1T/0H7t8MZK+ZMTN5bNc+sx/YIHt+o9kkTa+3mNx12hjtiwjJByIx1rtHSW+rpLb5gXD1C7A+165eHY68kLzMUCPhxUw6KnLGj3EIPqIa+Ae5k6CVIfNYts7CmI= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0656.namprd03.prod.outlook.com (10.160.96.18) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 29 Dec 2015 01:27:49 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0361.006; Tue, 29 Dec 2015 01:27:49 +0000 From: Christian Huitema To: Eric Rescorla Thread-Topic: [TLS] What does it mean to not include 0-RTT message in the handshake hash? Thread-Index: AdE8WUzTusUbdu5EQyy4pojDDNAspQAA40EAAACQIQAAAGOBgACJ8x0AAAJUsIAAAMc6AAAAcr0AAABvnYAAATEtgAAE47KAAHElnwAALTC/YAAOzi4AAByvZ/A= Date: Tue, 29 Dec 2015 01:27:48 +0000 Message-ID: References: <201512241748.25385.davemgarrett@gmail.com> <201512270208.11253.davemgarrett@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [72.235.151.78] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0656; 5:BzdkT/Tj4gXzd7bMZpTWztNBzLMGFQHSHpJzwsNI8EVPjkG7kgl5zSDG45c5oOFVrU6caX3sCcfKt5KquX4jFlmrsd6vMW5LoB7pc+VUHiPpjCZpIspJd6JC7FjBShQ7ObK07bOJ8f5v/zCpJS1djw==; 24:M3ubYiusqLguD1tnYoSYEAZ1ObWJPRbsLvgLS1/AaTrYwXhGf4zTz1Vnmr3oJNY4T1dQShkXk03FBMRI/al+aszkBy0Pi5Q7FaSnP/xb6/k= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0656; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001)(61426038)(61427038); SRVR:DM2PR0301MB0656; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656; x-forefront-prvs: 0805EC9467 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(199003)(189002)(2950100001)(5003600100002)(86362001)(11100500001)(54356999)(5001960100002)(105586002)(93886004)(66066001)(10090500001)(5004730100002)(92566002)(586003)(5008740100001)(99286002)(189998001)(5002640100001)(97736004)(81156007)(102836003)(15975445007)(77096005)(3846002)(6116002)(110136002)(1220700001)(1096002)(76176999)(106356001)(50986999)(122556002)(8990500004)(5005710100001)(2900100001)(10290500002)(74316001)(87936001)(33656002)(101416001)(10400500002)(86612001)(76576001)(40100003)(19580405001)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0656; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2015 01:27:49.1142 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0656 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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, 29 Dec 2015 01:28:17 -0000 DQoNCkZyb206IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dIA0KU2VudDogTW9u ZGF5LCBEZWNlbWJlciAyOCwgMjAxNSAxOjQ2IEFNDQpUbzogQ2hyaXN0aWFuIEh1aXRlbWEgPGh1 aXRlbWFAbWljcm9zb2Z0LmNvbT4NCkNjOiBEYXZlIEdhcnJldHQgPGRhdmVtZ2FycmV0dEBnbWFp bC5jb20+OyB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExTXSBXaGF0IGRvZXMgaXQgbWVh biB0byBub3QgaW5jbHVkZSAwLVJUVCBtZXNzYWdlIGluIHRoZSBoYW5kc2hha2UgaGFzaD8NCg0K DQoNCk9uIFN1biwgRGVjIDI3LCAyMDE1IGF0IDExOjU1IFBNLCBDaHJpc3RpYW4gSHVpdGVtYSA8 aHVpdGVtYUBtaWNyb3NvZnQuY29tPiB3cm90ZToNCk9uIFNhdHVyZGF5LCBEZWNlbWJlciAyNiwg MjAxNSA5OjA4IFBNLCBEYXZlIEdhcnJldHQgd3JvdGU6DQo+IE9uIFRodXJzZGF5LCBEZWNlbWJl ciAyNCwgMjAxNSAwODowODoyNSBwbSBFcmljIFJlc2NvcmxhIHdyb3RlOg0KPiA+IFdlbGwsIHRo aXMgaXMgYSBnZW5lcmFsIHJlcXVpcmVtZW50IGFueSB0aW1lIHRoZSByZWNvcmQgTUFDIGlzIGJh ZDoNCj4gPiBTZWUNCj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cCUzYSUyZiUyZnRsc3dnLmdpdGgNCj4gdWIuaW8lMmZ0bHMxMy0NCj4gc3Bl YyUyZiUyM3JmYy5zZWN0aW9uLjUuMi4yJmRhdGE9MDElN2MwMSU3Y2h1aXRlbWElNDBtaWNyb3Nv ZnQuY29tJTcNCj4gYzU3Yzg0MDRhMWYyZjQxYTE3ZjhhMDhkMzBlOGM4MjQzJTdjNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNA0KPiA3JTdjMSZzZGF0YT1uVGRoVTFjQzZ5YVlmS3ZwSUc0 SlIxdmhUZ3M4MmdGWWdWTEpiUFlza1hRJTNkDQo+ID4gIklmIHRoZSBkZWNyeXB0aW9uIGZhaWxz LCBhIGZhdGFsIOKAnGJhZF9yZWNvcmRfbWFj4oCdIGFsZXJ0IE1VU1QgYmUgZ2VuZXJhdGVkLiIN Cj4gPg0KPiA+IE9uIFRodSwgRGVjIDI0LCAyMDE1IGF0IDU6NDggUE0sIERhdmUgR2FycmV0dCA8 ZGF2ZW1nYXJyZXR0QGdtYWlsLmNvbT4NCj4gPiB3cm90ZToNCj4gPiA+IFRoZSBjdXJyZW50IHRl eHQgZG9lc24ndCBleHBsaWNpdGx5IHNheSBob3cgdG8gaGFuZGxlIDAtUlRUIGRhdGEgdGhhdCBp dA0KPiA+ID4gdGhpbmtzIGl0IHNob3VsZCBiZSBhYmxlIHRvIGRlY3J5cHQgYnV0IGNhbid0LiBB ZnRlciByZXJlYWRpbmcgdGhpbmdzIGEgYml0DQo+ID4gPiBJIHRoaW5rIHlvdSdyZSBjb3JyZWN0 IGluIHRoYXQgdGhlIGNvcnJlY3QgY291cnNlIG9mIGFjdGlvbiB0aGUgc3BlYw0KPiA+ID4gY3Vy cmVudGx5IGV4cGVjdHMgaXMgdG8gYWJvcnQsIGhvd2V2ZXIgaW1wbGVtZW50ZXJzIGZyZXF1ZW50 bHkgZXJyIG9uIHRoZQ0KPiA+ID4gc2lkZSBvZiB3b3JraW5nIHBhcnRpYWxseSB2cyBub3QgYXQg YWxsIHdoZW4gZ2l2ZW4gYW55IHdpZ2dsZSByb29tLiBBIGNsZWFyDQo+ID4gPiBoYXJkICJNVVNU IGFib3J0IiBvbiBmYWlsZWQgZGVjcnlwdCBvZiAwUlRUIGRhdGEgd291bGQgZGVhbCB3aXRoIHRo aXMgYW5kDQo+ID4gPiBhdm9pZCBhbnkgb3RoZXIgcG9zc2libGUgbWlzdW5kZXJzdGFuZGluZy4g RWl0aGVyIGRvIG9yIGRvIG5vdDsgbm8gdHJ5Lg0KPiA+DQo+ID4gSWYgeW91IGhhdmUgc3VnZ2Vz dGVkIHRleHQsIEknZCBiZSBoYXBweSB0byBzZWUgYSBQUi4NCj4NCj4gT2ssIEkgZmlsZWQgUFIg MzkzIHdpdGggYSBjb3VwbGUgc2VudGVuY2VzIHRvIGNsYXJpZnkgdGhhdCAwLVJUVCByZWNvcmRz IGFyZW4ndA0KPiBhbGxvd2VkIHNwZWNpYWwgdHJlYXRtZW50IGFuZCBlcnJvcnMgb24gaGFuZGxp bmcgTVVTVCBOT1QgcmVzdWx0IGluIGEgMS1SVFQNCj4gZmFsbCBiYWNrLg0KDQpJc24ndCB0aGF0 IGEgcGFydCB3aGVyZSBUTFMgYW5kIERUTFMgd2lsbCBkaWZmZXIgYSBsb3Q/DQoNCkZvciBEVExT LCB3ZSBoYXZlIHRvIGNvbnNpZGVyIHRoZSBwYWNrZXQgaW5qZWN0aW9uIHRocmVhdC4gSXQgaXMg ZmFpcmx5IGVhc3kgdG8gc2VuZCBzb21lIHJhbmRvbSBieXRlcyB3aXRoIGEgZmFrZSBzb3VyY2Ug dG8gYSBVRFAgZGVzdGluYXRpb24uIFN1Y2ggYXR0YWNrcyBzaG91bGQgbm90IGNhdXNlIHRoZSBE VExTIGFzc29jaWF0aW9uIHRvIGZhaWwhIFRoZSBub3JtYWwgYmVoYXZpb3Igb3VnaHQgdG8gYmUg dG8ganVzdCBpZ25vcmUgVURQIHBhY2tldHMgdGhhdCBmYWlsIHRvIGRlY3J5cHQuIFRoaXMgd291 bGQgY2F1c2UgMC1SVFQgcmVqZWN0cyB0byBqdXN0IHJlc3VsdCBpbiBkcm9wcGVkIHBhY2tldHMu IENhbiB3ZSBlbnN1cmUgdGhhdCB0aGUgaGFuZHNoYWtlIHByb3RvY29sIGlzIHJvYnVzdCBhZ2Fp bnN0IHRoYXQ/DQoNCldlIG9idmlvdXNseSBuZWVkIHRvIGRpc3Rpbmd1aXNoIGhlcmUgYmV0d2Vl biBoYW5kc2hha2UgYW5kIGFwcGxpY2F0aW9uDQpkYXRhIG1lc3NhZ2VzLCBiZWNhdXNlIERUTFMg aXMgaW50ZW5kZWQgdG8gYWxsb3cgbG9zcyBvZiBhcHBsaWNhdGlvbiBkYXRhDQptZXNzYWdlcy4N Cg0KV1JUIGhhbmRzaGFrZSBtZXNzYWdlcywgYXMgSSBpbmRpY2F0ZWQgYmVmb3JlLCBJIGJlbGll dmUgdGhhdCB0aGVyZSBpcw0KZW5vdWdoIGluZm9ybWF0aW9uIGluIHRoZSBoYW5kc2hha2UgbWVz c2FnZXMgdG8gcHJldmVudCByZW1vdmFsLg0KTmFtZWx5Og0KDQoxLiBUaGUgQ2xpZW50SGVsbG8g Y29udGFpbnMgYW4gaW5kaWNhdGlvbiB0aGF0IDAtUlRUIGhhbmRzaGFrZSBtZXNzYWdlcw0KYXJl IGNvbWluZy4NCjIuIFRoZSBDbGllbnQncyAwLVJUVCBGaW5pc2hlZCBjb250YWlucyBhIE1BQyBv ZiBhbGwgdGhlIENsaWVudCdzDQowLVJUVCBtZXNzYWdlcy4NCjMuIFRoZSBTZXJ2ZXIncyBGaW5p c2hlZCBjb250YWlucyBhIE1BQyBvZiB0aGUgQ2xpZW50SGVsbG8uDQoNClRodXMsIHByb3ZpZGVk IHRoYXQgdGhlIGNsaWVudCBhbmQgc2VydmVyIGluIGZhY3Qgc2hhcmUgYSBjb25maWd1cmF0aW9u DQood2hpY2gsIGFnYWluLCBpcyBpbiB0aGUgQ2xpZW50SGVsbG8pIHRoZW4gdGhlIHNlcnZlciBr bm93cyBhdCB0aGUgdGltZQ0Kb2YgcmVjZWl2aW5nIHRoZSBmaXJzdC1mbGlnaHQgRmluaXNoZWQg dGhhdCBoZSBoYXMgKG9yIGhhcyBub3QpIHJlY2VpdmVkDQphbGwgdGhlIGNsaWVudCdzIDAtUlRU IEhhbmRzaGFrZSBtZXNzYWdlcy4gWzBdLg0KDQoNClRoZSBtb3JlIGludGVyZXN0aW5nIHF1ZXN0 aW9uLCBob3dldmVyLCBpcyB3aGF0IGRyaXZlcyB0aGUgRFRMUyBzdGF0ZQ0KbWFjaGluZSBmb3J3 YXJkIHRvIGVuc3VyZSBwcm9ncmVzcyBpbiB0aGUgZmFjZSBvZiBpbm5vY3VvdXMgbG9zcy4NClRo ZSBiYXNpYyBEVExTIGRlc2lnbiBpcyB0aGF0IHRoZSByZWNlaXB0IG9mIHRoZSBmaXJzdCBtZXNz YWdlIG9mIHRoZQ0KcGVlcidzIG5leHQgZmxpZ2h0IGluZGljYXRlcyByZWNlaXB0IG9mIHRoZSBl bnRpcmUgZmxpZ2h0LiBJbiB0aGlzIGNhc2UsDQp0aGVuLCB0aGUgcmVjZWlwdCBvZiB0aGUgU2Vy dmVySGVsbG8gd291bGQgaW5kaWNhdGUgcmVjZWlwdCBvZiB0aGUNCkNsaWVudCdzIDAtUlRUIEZp bmlzaGVkLiBIb3dldmVyLCB0aGlzIHdvdWxkIHBsYWNlIGEgcmVxdWlyZW1lbnQNCnRoYXQgdGhl IHNlcnZlciBub3QgKnNlbmQqIHRoZSBTZXJ2ZXJIZWxsbyB1bnRpbCB0aGF0IHBvaW50LCB3aGlj aCB3ZSd2ZQ0KbGVmdCBvcGVuIGluIFdJUC0xMSBieSBub3QgaGFzaGluZyBpbiB0aGUgMC1SVFQg cGxhaW50ZXh0Lg0KDQotRWtyDQoNClswXSBOb3RlLCBob3dldmVyLCB0aGF0IHRoZSBjbGllbnQg aGFzIHRvIHJlbHkgb24gdGhlIHNlcnZlciB0byBoYW5kbGUgdGhpcw0KcHJvcGVybHkuIFRoZSBy ZWFzb24NCg0K From nobody Mon Dec 28 23:12:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B6A1A1B91 for ; Mon, 28 Dec 2015 23:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 Ry-vBGlBkOD8 for ; Mon, 28 Dec 2015 23:12:14 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 981021A1B92 for ; Mon, 28 Dec 2015 23:12:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 8DEA18D; Tue, 29 Dec 2015 09:12:12 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id F04IEX-FM1sm; Tue, 29 Dec 2015 09:12:12 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 3F638138; Tue, 29 Dec 2015 09:12:12 +0200 (EET) Date: Tue, 29 Dec 2015 09:12:11 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20151229071211.GA21692@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft -11 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Dec 2015 07:12:17 -0000 On Mon, Dec 28, 2015 at 02:52:49PM -0500, Eric Rescorla wrote: > Folks, > > In the spirit of making a useful checkpoint, I just posted the latest > version of the > editor's draft as draft-11. Here's the major changes: > > > - Unify authentication modes. Add post-handshake client authentication. I noticed the following: 1) In previous drafts with the OPTLS design, 1-RTT Finished messages used SS as key (for avoiding circular logic or something like that). But -11 seems to specify Master Secret. 2) Post-handshake auth seems to need hash forking, whereas everything else (except 0-RTT, which likely gets implemented differently anyway) only needs multitap hashes (even for CertificateVerify). 3) If any extension tries to add new message between ServerConfiguration and Certificate or Finished and Certificate, the defintion goes screwy (one expects the hash to end just before Certificate). And there are two non-deprecated extensions that do just that... 4) There is also one (infamous) extension (not deprecated) that uses Supplemental Data mesage from server to client. Where does that message go? Right after EncryptedExtensions (one creative interpretation)? > The major open issues I am aware of are: > > - Details of state pickling for stateless reject. I owe the list a proposal > here. This a bit more subtle than it seems. Looks like you need to put the Client Random in that state too, in order to avoid rehandshakes from blowing up. The server needs some way of telling apart a retry and a rehandshake, otherwise it tries to recover the state on rehandshake, which is very wrong and won't work. Also, I would set the default maximum TTL at 0 (don't save between connections unless application profile says so). -Ilari From nobody Mon Dec 28 23:15:12 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBFE1A1B95 for ; Mon, 28 Dec 2015 23:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, T_RP_MATCHES_RCVD=-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 BrCNegk-si-V for ; Mon, 28 Dec 2015 23:15:09 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 10D9E1A1B92 for ; Mon, 28 Dec 2015 23:15:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 367D8D2; Tue, 29 Dec 2015 09:15:08 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id dnGKyiT68hpt; Tue, 29 Dec 2015 09:15:08 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id E7FBD138; Tue, 29 Dec 2015 09:15:07 +0200 (EET) Date: Tue, 29 Dec 2015 09:15:07 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20151229071507.GA21772@LK-Perkele-V2.elisa-laajakaista.fi> References: <201512241748.25385.davemgarrett@gmail.com> <201512270208.11253.davemgarrett@gmail.com> <20151228214915.GB5798@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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, 29 Dec 2015 07:15:10 -0000 On Mon, Dec 28, 2015 at 06:59:48PM -0500, Eric Rescorla wrote: > On Mon, Dec 28, 2015 at 4:49 PM, Ilari Liusvaara > wrote: > > > > Also, on topic of DTLS 1.3... It occurs to me that naively doing it > > would leave it open to "fragementation attacks" a'la IPv6. > > > > Basically, it occurs to me that ClientHello messages SHOULD NOT be > > fragmented (at TLS level, SCTP(?) or IP level fragmentation is another > > kettle of fish) and if it is fragmented, the Cookie extension MUST be > > in the first fragment. > > Sorry, I'm not sure I am processing this. Can you explain in more detail. Basically, the server should avoid keeping any state for what it is going to reject (because keeping such state would be pretty major DoS vector). And no state means no fragment reassembly and only first fragment being parseable. And it is not only Cookie that can generate rejects, but also KeyShare. -Ilari From nobody Tue Dec 29 04:00:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF1B1A8729 for ; Tue, 29 Dec 2015 04:00:54 -0800 (PST) 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 Z70zU1T9zX45 for ; Tue, 29 Dec 2015 04:00:52 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0141.outbound.protection.outlook.com [65.55.169.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0A771A872B for ; Tue, 29 Dec 2015 04:00:51 -0800 (PST) Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB123.namprd09.prod.outlook.com (10.255.200.25) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 29 Dec 2015 12:00:49 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0361.006; Tue, 29 Dec 2015 12:00:49 +0000 From: "Dang, Quynh" To: "tls@ietf.org" Thread-Topic: [TLS] Data volume limits Thread-Index: AQHRN326ECu0fHUB6EGja4Q2uc5EIJ7NTTAHgAAqpwCAAJE6gIAAzzaAgAAu9YCAAc3M+oARFmPU Date: Tue, 29 Dec 2015 12:00:49 +0000 Message-ID: References: <87twnibx5p.fsf@latte.josefsson.org> <1450340361.7118.5.camel@redhat.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-originating-ip: [129.6.222.165] x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:1+HpTiy6xfn2DDl/CP9vo1xtf6xYY069iIiaIpMj8TVb1RNyBpmnvPq/0xpJxRorT0yG0gvaB2iUg75Ea3A8gNAMJdT7VHzMpZKj9Hqeun0Ekik2WH5Iu7mGKHsOI6oit59G8fHh+9ZDu4yGvrNH7Q==; 24:mVITaID88w4sBFIP7UI2kBlllrlUbNfNb/fUbMr4BTiDcarakqdsgwKwiUv3SUEJuK7rUhZAfTcSTpyniaWHdoOyYDVKhVkx/661rMpxBFE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123; x-forefront-prvs: 0805EC9467 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(31014005)(53754006)(377454003)(377424004)(199003)(24454002)(101416001)(4001150100001)(189998001)(92566002)(106356001)(5004730100002)(5002640100001)(74316001)(102836003)(2501003)(586003)(76176999)(5008740100001)(107886002)(99286002)(2900100001)(5001960100002)(3846002)(6116002)(1730700002)(1096002)(97736004)(110136002)(81156007)(11100500001)(1220700001)(2950100001)(5003600100002)(54356999)(122556002)(86362001)(87936001)(15975445007)(40100003)(19580405001)(50986999)(77096005)(106116001)(33656002)(450100001)(93886004)(19580395003)(105586002)(66066001)(76576001)(2351001)(10400500002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2015 12:00:49.4275 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB123 Archived-At: Subject: Re: [TLS] Data volume 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: Tue, 29 Dec 2015 12:00:54 -0000 Hi all, Rekeying too often unnecessarily does not increase any cryptographic securi= ty. In addition, it could create other cryptographic issues for the system.= The first issue is key collision risk when AES-128 is used and the second = issue could be multi-target (multi-key) risk theoretically.=20 Therefore, I would suggest not to rekey (as currently specified) too often = unnecessarily.=20 I think providing a data limit guidance sub-section under the Security Cons= ideration section is one good option to be considered. Users just follow th= e guidance to set their own data limit(s).=20 Quynh.=20 ________________________________________ From: TLS on behalf of Dang, Quynh Sent: Friday, December 18, 2015 10:49 AM To: tls@ietf.org Subject: Re: [TLS] Data volume limits The collision probability of ciphertext blocks also depends on the size of = the plaintext (record size in a TLS implementation) in each call of the GC= M encryption function. Let's call each plaintext to be 2^x 128-bit blocks= . TLS 1.3 uses 96-bit IV. If someone wants the collision probability below 1/2^y such as 1/2^24 or 1/= 2^32 (2^32 =3D 4,294,967,296 and 2^24 =3D 16,777,216 ), the total number of= plaintext blocks under a given key must be 2^((96 + x - y)/2) or lower. So, 2^((96 + x - y)/2) 128-bit blocks are the limit to achieve IND-* with = GCM. If someone does not need IND-* property, the above restriction is not neede= d. Quynh. ________________________________________ From: TLS on behalf of Yoav Nir Sent: Thursday, December 17, 2015 6:07 AM To: Nikos Mavrogiannopoulos Cc: tls@ietf.org; Simon Josefsson Subject: Re: [TLS] Data volume limits > On 17 Dec 2015, at 10:19 AM, Nikos Mavrogiannopoulos wr= ote: > > On Wed, 2015-12-16 at 09:57 -1000, Brian Smith wrote: > >> Therefore, I think we shouldn't add the rekeying mechanism as it is >> unnecessary and it adds too much complexity. > > Any arbitrary limit for a TLS connection is almost guaranteed to cause > problems in the future. We cannot predict whether 2^x should be > sufficient for everyone, and I'm pretty sure this will prove to be a > terrible mistake. TLS is already being used for VPNs and transferring > larger amounts of data in long lived connections is a reality even > today. The rekey today happens using the reauthentication mechanism, > which has very complex semantics. Converting these to a simpler and > predictable rekey mechanism would be an improvement. Agreed. The alternative to having a rekey mechanism is to push the complexi= ty to the application protocol, requiring it to be able to use more than on= e connection to transfer all the data, which may require some sort of sessi= on layer to maintain state between connections. So unless we can guarantee or require that every algorithm we are going to = use is good for some ridiculous amount of data (2^64 bytes may be enough), = we need rekeying. Yoav _______________________________________________ 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= From nobody Tue Dec 29 11:02:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839C71A0856 for ; Tue, 29 Dec 2015 11:02:29 -0800 (PST) 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, 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 to5xw0XsXyzt for ; Tue, 29 Dec 2015 11:02:26 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF2A1A03A2 for ; Tue, 29 Dec 2015 11:02:26 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id o124so191983721oia.1 for ; Tue, 29 Dec 2015 11:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v+I0zBdV0GtkkJhIp0Gg1nc2tAsAWTxadl9+gHia154=; b=LNqLmXTwRFsvQm8d8Cvv9x/zi8Wks4+atUb/TOWZRpZ/9J3+ul1qUR3vkDWnRv/vgr LPPQDc8+RTD1Docz8VPFZK3YhaEH5qySBfsLbtDQwgPv9GWx6RpKDdSKj3Cv2yD8sZwm UPVqPoK+q2tAqdtJMCMaDABu6bgXx4khVoVNHjdXrhIrJkKEvWz9ZwQqXbcfIxVWQOgP Cs6CL3am7ylIqGinTSCkPMi2q53wT5ziA4yFpMDMa7dq3abktSIiQyMd5/LFOFuB0oYr eqI/p+nv6y0zzGteJ2ZFflIm/AUgICrOmyM5uwvYHXqGFh99GhdWhz/YPMP+/5xZW4QW 9kow== 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=v+I0zBdV0GtkkJhIp0Gg1nc2tAsAWTxadl9+gHia154=; b=Uw4JGuhYaxb80OkHSF0OUxfCv0SoKPzGM4p9YnhwKoFFArV7oAlONcBvi0kEGRnnz2 CLmTeJYdoxD46LpcTRgr0R6JlFLJZQAaASLrHsEw7f5YBYPHgK/o+v8AOZJhwsgAXJVa DkkCgAaSijXRoQfpFhD01X+HxRJybv8DKeV8lutbOmpcOaTgr5WxNpKh76wlgQSo8iOQ 8gESjLbui7BD4z99O8EJAIW4nim8Ob7oDWR/cJGkmjFQh1+kDvfWolM4bQyMxa5jsqcr lSTFxyRycWMzxCPgf+aBV66C0WVwX0OoJrOiJybeKshT+yFP5PRTMZQFEwXwI/9DhY17 mC0w== X-Gm-Message-State: ALoCoQnN6JGPjN5sqzUY1USxAJQ4M/UL7nbSegi6A3zVivpqQxzDwaMhQEzPofHlJiuPM5ZW/SCSI6t22L7D/aVNwSFAQiYIOw== MIME-Version: 1.0 X-Received: by 10.202.189.7 with SMTP id n7mr36962603oif.55.1451415745711; Tue, 29 Dec 2015 11:02:25 -0800 (PST) Received: by 10.76.62.8 with HTTP; Tue, 29 Dec 2015 11:02:25 -0800 (PST) In-Reply-To: References: Date: Tue, 29 Dec 2015 09:02:25 -1000 Message-ID: From: Brian Smith To: Adam Langley Content-Type: multipart/alternative; boundary=001a113d7032f1e76f05280e0f4e Archived-At: Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Dec 2015 19:02:29 -0000 --001a113d7032f1e76f05280e0f4e Content-Type: text/plain; charset=UTF-8 Adam Langley wrote: > On Tue, Dec 22, 2015 at 3:15 PM, Brian Smith wrote: > > I still think there is value in requiring senders to send their public > value > > in the "normalized" form and for allowing (if not requiring) receivers to > > reject, at least, public values >= q, for the reasons I gave in my > previous > > email. Ideally that would happen in the CFRG document. But, what is the > > status of the CFRG document? I've heard that it's past the point where > > changes will be accepted. > > The CFRG document is in AUTH48 right now so, indeed, it's probably too > late for that sort of change. > > To give some background about why the CFRG document ended up the way it > did: > > The curve25519 paper only mentions the extra bit to say: "Note that > Curve25519 is not surjective: in particular, its final output bit is > always 0 and need not be transmitted." [1]. It didn't specify whether > it should be ignored or not and implementations started to differ on > that point. Does that matter, though? The CFRG document doesn't allow the sender to set the high bit to 1, right? In particular, it says "All calculations are performed in GF(p), i.e., they are performed modulo p." and "For X25519, the unused, most-significant bit MUST be zero." If the receiver can detect that the sender is non-conforming, then it should be able to stop talking to it on that basis alone. > Also, in order to keep the code simple, it didn't check > for values >= 2^255-19. Both because that could be more code in the > primitive itself, and because it would mean that the function would > change from being total to partial. > I think there is value in it being a total function. But, I think there is value in checking the conformance of the sender in the receiver. Note that such a check can be layered on top of the X25519 primitive. No implementations rejected values >= 2^255-19 from what I recall. > I do have a private implementation that does this check, not just for X25519 but for basically all ECC calculations. I don't want to have to make Curve25519 special in allowing non-canonical/non-reduced values when all the rest of my code doesn't allow such cases, especially when the CFRG spec already forbids implementations from sending the non-canonical/non-reduced values. > > Since the CFRG has standardised Curve25519, in practice the existing > implementations will seed the implementation ecosystem. Changing > something really subtle like the extra bit behaviour, or rejecting > oversized values, without a clear need, doesn't seem to me to be > worthwhile (or, perhaps, even achievable for a spec). > As long as senders conform to the spec, they will not notice what the receiver does regarding this. Cheers, Brian -- https://briansmith.org/ --001a113d7032f1e76f05280e0f4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adam= Langley <agl@imperialviolet.org> wrote:
On Tue, Dec 22, 2015 at 3:15 PM, Brian Smith <brian@briansmith.org> wrote:> I still think there is value in requiring senders to send their publi= c value
> in the "normalized" form and for allowing (if not requiring)= receivers to
> reject, at least, public values >=3D q, for the reasons I gave in m= y previous
> email. Ideally that would happen in the CFRG document. But, what is th= e
> status of the CFRG document? I've heard that it's past the poi= nt where
> changes will be accepted.

The CFRG document is in AUTH48 right now so, indeed, it's probab= ly too
late for that sort of change.

To give some background about why the CFRG document ended up the way it did= :

The curve25519 paper only mentions the extra bit to say: "Note that Curve25519 is not surjective: in particular, its final output bit is
always 0 and need not be transmitted." [1]. It didn't specify whet= her
it should be ignored or not and implementations started to differ on
that point.

Does that matter, though? The C= FRG document doesn't allow the sender to set the high bit to 1, right? = In particular, it says "All calculations are performed=C2=A0in GF(p), i.e., they are performed modulo p.&qu= ot; and "F= or X25519, the unused, most-significant bit MUST be=C2=A0zero."

If the receiver can= detect that the sender is non-conforming, then it should be able to stop t= alking to it on that basis alone.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> Also, in order to keep the code simple, it didn't chec= k
for values >=3D 2^255-19. Both because that could be more code in the primitive itself, and because it would mean that the function would
change from being total to partial.

I t= hink there is value in it being a total function. But, I think there is val= ue in checking the conformance of the sender in the receiver. Note that suc= h a check can be layered on top of the X25519 primitive.

No implementations rejected values >=3D 2^255-19 from= what I recall.

I do have a private imp= lementation that does this check, not just for X25519 but for basically all= ECC calculations. I don't want to have to make Curve25519 special in a= llowing non-canonical/non-reduced values when all the rest of my code doesn= 't allow such cases, especially when the CFRG spec already forbids impl= ementations from sending the non-canonical/non-reduced values.

Since the CFRG has standardised Curve25519, in practice the existing
implementations will seed the implementation ecosystem. Changing
something really subtle like the extra bit behaviour, or rejecting
oversized values, without a clear need, doesn't seem to me to be
worthwhile (or, perhaps, even achievable for a spec).
=
As long as senders conform to the spec, they will not notice= what the receiver does regarding this.

Cheers,
Brian
--
--001a113d7032f1e76f05280e0f4e-- From nobody Tue Dec 29 11:05:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534201A1B1D for ; Tue, 29 Dec 2015 11:05:19 -0800 (PST) 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, 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 UxtUmRG62fcc for ; Tue, 29 Dec 2015 11:05:18 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18AD81A03A2 for ; Tue, 29 Dec 2015 11:05:18 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id y66so192310252oig.0 for ; Tue, 29 Dec 2015 11:05:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oXi+arw/ssB4gd7pZ/bVBwSoVRJjMLOPTKI8RwLiDxg=; b=FFhD/CO15C7MwlWyfzBHvdsGGEcseJBXxhnd5gRuH0abklwPbP+2R6OcLj4IN+pCNY vKWYqOSNEDBuESdw/LLzdai7QPnHOQYGo5ATONtOPQ2paY8uu353xTBj+M2+63T8W5Gg CAiPZpj4j6bhPJ9xx1bULTWeQRw1uoyPfbQmlNzlSOk6TMJOu+JqLDsVG2rWbVwpRlgA 36ZHwKmVq+DrJdnhJMpC02QIktcfikM2DRNNvRYfKnPN6Rh9hAH6TJ2IQSw5e+9kDFMw MDy6xJTIVjJ+UGMLR8z9sQpO/46uX0K2UON0mUE7sflNKYxmUpvBk1WWSCv0DAou+nxF tw1w== 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=oXi+arw/ssB4gd7pZ/bVBwSoVRJjMLOPTKI8RwLiDxg=; b=lvZs1u3V2fWW76Kth6gSSntLCeo6F8CFqvI08tac61yXxk/2GF8I/NQJ7lpyyLXrVk rfnNQWJBfebDqqKZhyrazxcf+ZKxn3qVQ00WyHyNHKbq4JusQpL2bL+5+wtMdIBBKUpI AmuH4KlUFrbOM01IsIufgHye07kNC8C9FNSNMrJBU1jcoGLedzSBcbW7RafOZnh5ugyA NOFxHCJvtcAGzO6xRipKi9YJJpqKJEJ89wdwnVzoju4wZ53jX+yjFOTXI1LeaNSkB3GG hgRWcnKubXYivPojspvPo8QyySm3rV90dKroXMTLPqvPUn/HY7q1QBEtaGYqSocoagN6 orEw== X-Gm-Message-State: ALoCoQl0+m0TnqWmhcJebFGSx4LQvDvFB0t391AGC3/VCuBKwBr8FDB9bde0slhcGSL4Gge7ilA89zhhpqF8vHU1sNUI4qQeMQ== MIME-Version: 1.0 X-Received: by 10.202.189.7 with SMTP id n7mr36975443oif.55.1451415917422; Tue, 29 Dec 2015 11:05:17 -0800 (PST) Received: by 10.76.62.8 with HTTP; Tue, 29 Dec 2015 11:05:17 -0800 (PST) In-Reply-To: References: Date: Tue, 29 Dec 2015 09:05:17 -1000 Message-ID: From: Brian Smith To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113d70322df07505280e1a8a Archived-At: Cc: "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Dec 2015 19:05:19 -0000 --001a113d70322df07505280e1a8a Content-Type: text/plain; charset=UTF-8 On Tue, Dec 22, 2015 at 2:09 PM, Brian Smith wrote: > If an implementation only implements ECDHE cipher suites then > implementing the session hash extension is not necessary, according to RFC > 7627. I believe there are also a few other factors that would implementing > the session hash extension to be unnecessary. > > If checking that the shared value isn't zero is sufficient, and/or > blacklisting the public values that DJB mentions in [1] is sufficient, > either would be better than mandating the implementation of the session > hash extension just for this purpose. > Actually, the check for a result of zero is already required in the current CFRG draft; see [1]. So, I think that the easiest way to fix the TLS draft is to just delete the misleading text. [1] https://tools.ietf.org/html/draft-irtf-cfrg-curves-11#section-6.1 Cheers, Brian -- https://briansmith.org/ --001a113d70322df07505280e1a8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 22, 2015 at 2:09 PM, Brian Smith <brian@briansmith.org><= /span> wrote:
If an implementation only implements=C2=A0ECDHE cipher suites then implemen= ting the session hash extension is not necessary, according to=C2=A0= RFC 7627. I bel= ieve there are also a few other factors that would implementing the session= hash extension to be unnecessary.

If checking that the share= d value isn't zero is sufficient, and/or blacklisting the public values= that DJB mentions in [1] is sufficient, either would be better than mandat= ing the implementation of the session hash extension just for this purpose.=

Actually, the ch= eck for a result of zero is already required in the current CFRG draft; see= [1]. So, I think that the easiest way to fix the TLS draft is to just dele= te the misleading text.


Cheers,
Brian
--
--001a113d70322df07505280e1a8a-- From nobody Tue Dec 29 11:10:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F06D1A702C for ; Tue, 29 Dec 2015 11:10:27 -0800 (PST) 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, 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 MjX0vI5x-ZYa for ; Tue, 29 Dec 2015 11:10:26 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11C641A21B4 for ; Tue, 29 Dec 2015 11:10:26 -0800 (PST) Received: by mail-ob0-x235.google.com with SMTP id ba1so164828880obb.3 for ; Tue, 29 Dec 2015 11:10:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f3CT0Blxkz89kciKkN5d9672AeiR0qKXYBShJZ82E8g=; b=S5t5GfodjqFVK7FSdymOQEvWNGdGi3fsoY7zpZ/GK4OoeFlauHlrI0h5QvOO5HhztC VNggPxpQuuc0DrmmHzPq8hyavv1BjHDGej5HHXzKUY8K7mZneqMfnuwZj10cIlOyttaK c6QLahv9PHmSaQn0vLLYJUT+SVIlPge2FeGBeTmSGO3VbdF251QZlpgQ7mZRaWs2MTFU bHWfx/zX3MhAkCL3WQZwGSEWejWrWHK2XyS5KD4L2/lWBDsiowr+MdosJva8hi+w9iFU v8aEhcrRBHPhmfRmg9Bzvhz0Z7hk0w4YGAZvzMQQBXbEFwux+XskPJ0F+Ahxbfea0PB3 GWiw== 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=f3CT0Blxkz89kciKkN5d9672AeiR0qKXYBShJZ82E8g=; b=kTRnwMCJzC0h8c0pgRp7+YHLzjl3Z6xbEH1i7gvh65CBsRvHrymT6UN8t48cNOdpnG LFsKzfALrzIXAwfzL5Jl2GjzeG4+/uiqskW4fPIIcOH2uBnL8B4Bw0vsahOupzMJ1B01 0VurSouVlbY2q0QpgIt3MgksXqnbpgx5pR/6wxbHobBQFShS2+FVlFtBaetF4pODIr5i 7DBSfbDWMDizMakATUJbuy9J+sTpog0kUqSov8mCCaUdTuwNZWXf/N4ZMBIrvFAc1bYB u/glwr2JJ9guloTwMwWxom4xlk+kbShpqDg9/KgYZ+JdyjztcdAVvdNL3rVyJrkmSAYy u73Q== X-Gm-Message-State: ALoCoQmP3eneH9kaC3JYhlh67o3/DHPlarMXsQAf3wNKUmH64aqrocJCHuSlrBiAbRZFzD4HKiyR2EQOKYAIzVYj4S2rmPofXA== MIME-Version: 1.0 X-Received: by 10.60.134.202 with SMTP id pm10mr8333764oeb.50.1451416225507; Tue, 29 Dec 2015 11:10:25 -0800 (PST) Received: by 10.76.62.8 with HTTP; Tue, 29 Dec 2015 11:10:25 -0800 (PST) In-Reply-To: <20151228205610.GA5798@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151228205101.17780804.92503.42669@ll.mit.edu> <20151228205610.GA5798@LK-Perkele-V2.elisa-laajakaista.fi> Date: Tue, 29 Dec 2015 09:10:25 -1000 Message-ID: From: Brian Smith To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=047d7b417a638b241d05280e2c2b Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Tue, 29 Dec 2015 19:10:27 -0000 --047d7b417a638b241d05280e2c2b Content-Type: text/plain; charset=UTF-8 Ilari Liusvaara wrote: > OTOH, you can't drop an attacker knowing older key without doing > new key exchange. > I think it would be very unfortunate to have the complexity of key update (the new keys are derived from the old keys) without having the benefits of rekeying (the new keys are independent of the old keys). Note that NIST Special Publication 800-133 [1] defines these separate terms, and I suggest we use them in this conversation to avoid confusion: Key update: A procedure in which a new cryptographic key is computed as a function of the (old) cryptographic key that it will replace. Rekey: A procedure in which a new cryptographic key is generated in a manner that is independent of the (old) cryptographic key that it will replace. [1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133.pdf . Cheers, Brian -- https://briansmith.org/ --047d7b417a638b241d05280e2c2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ilar= i Liusvaara <ilariliusvaara@welho.com> wrote:
OTOH, you can't drop an attacker knowing older key without= doing
new key exchange.

I think it would be v= ery unfortunate to have the complexity of key update (the new keys are deri= ved from the old keys) without having the benefits of rekeying (the new key= s are independent of the old keys).

Note that NIST= Special Publication 800-133 [1] defines these separate terms, and I sugges= t we use them in this conversation to avoid confusion:

=
Key update: A procedure in which a new cryptographic key is computed a= s a function of the (old) cryptographic key that it will replace.

Rekey:=C2=A0A procedure in which a new cryptographic key is= generated in a manner that is independent of the (old) cryptographic key that it will replace.=C2=A0


Cheers,
Brian
--
--047d7b417a638b241d05280e2c2b-- From nobody Tue Dec 29 11:34:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284E21A88EF for ; Tue, 29 Dec 2015 11:34:20 -0800 (PST) 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, HTML_MESSAGE=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 rXrZWo-zheG3 for ; Tue, 29 Dec 2015 11:34:19 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85A41A88ED for ; Tue, 29 Dec 2015 11:34:18 -0800 (PST) Received: by mail-yk0-x232.google.com with SMTP id a85so60555772ykb.1 for ; Tue, 29 Dec 2015 11:34:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=R9aLyG2i85D2+q2LyosUZtvH+sKlo+Unl9At6CipBtE=; b=oRBuoFKUQltHBgVCL6XFoDPZwI8Y1E5DGQfLcWOJcsGKHR+F2tLPPX8Pc4Wd5f0Bmy d9Gfoqkv9ng4sceo+OTL5SadfnPjA9WFNyUuPU/fPqbWUBdOOAxUqbjS6hTaZ12UXA38 PixCgUftBjrNppApJdncw+Ozk0iXYJwk8UF7FHBzcxwyZeK9CraAx8JqxhBdAaRbMbK1 7PDQNsSBXjy10JtfOpytQZEd7PGFeLHWhWiiuuzEluc5u8ExiWZPjQ9OqiVgMfO8S8Xp KD2c/NVXnxWE/e7x6wfpmK0vtQzIYUvJeR4Bvm/D3XsvWfFJAyjZiEq/XWuGBT3oLnDw IJAA== 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=R9aLyG2i85D2+q2LyosUZtvH+sKlo+Unl9At6CipBtE=; b=bsAaid3KKLtmbzEgmZQQEeTtH9C5gkfFAtiThYF1oPY8wPhe8N/bP8Kj5c5J5BrNla 3X08isxo0dy8eWQoKuueCsBVUfkkJFPXagOR2ZO+shPA0uhEwI8EddquUi2vgZjMwSrQ feqj/hnHk/uCd1ZMCfAgAzCIvkcBfMQYLn+XgJHxXMW6wmZhE5rm6X4uvhe0+w1pX3Ho bK5pMG1vG/zsCT1PwhXbBVCcm71ZqGst9Rz3rLUYMF8K4FF/24vl3Z+RSZTA+Wi/wml+ buSavQAyQUHZFt4164lO4nbPU+0pDv6CbM+Dwm+1MLPP0t3c0QXAx7pYnhZ9DX+I0hi+ +HoA== X-Gm-Message-State: ALoCoQnRHy8ZLg8N/LD6BcZzjWeb/jjy9ZcVySjXLZ3elPrWN0dzCnVjO+nyZi2UsJJBaOnbvBrt1rM+HDi+NQ7cGO/Wi63WKQ== X-Received: by 10.129.46.208 with SMTP id u199mr44906010ywu.129.1451417658073; Tue, 29 Dec 2015 11:34:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 29 Dec 2015 11:33:38 -0800 (PST) In-Reply-To: References: <20151228205101.17780804.92503.42669@ll.mit.edu> <20151228205610.GA5798@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Tue, 29 Dec 2015 14:33:38 -0500 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=001a11408592ee564e05280e8110 Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Tue, 29 Dec 2015 19:34:20 -0000 --001a11408592ee564e05280e8110 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 29, 2015 at 2:10 PM, Brian Smith wrote: > Ilari Liusvaara wrote: > >> OTOH, you can't drop an attacker knowing older key without doing >> new key exchange. >> > > I think it would be very unfortunate to have the complexity of key update > (the new keys are derived from the old keys) without having the benefits of > rekeying (the new keys are independent of the old keys). > Note: the keys here are *not* derived from the old keys. Rather, they are derived via a KDF from the same secret that was used to generate the old keys. I.e., K_send_0 = KDF(MK_0, ) K_recv_0 = KDF(MK_0, ) MK_1 = KDF(MK_0, ) K_send_1 = KDF(MK_1, ) K_recv_1 = KDF(MK_1, ) Note that NIST Special Publication 800-133 [1] defines these separate > terms, and I suggest we use them in this conversation to avoid confusion: > > Key update: A procedure in which a new cryptographic key is computed as a > function of the (old) cryptographic key that it will replace. > > Rekey: A procedure in which a new cryptographic key is generated in a > manner that is independent of the (old) cryptographic key that it will > replace. > Hmm... It seems to me that there are three (at least) three separate possible designs: 1. Generate the new keys by a new application of the KDF with no additional inputs. 2. Generate the new keys by a new application of the KDF with additional random inputs. 3. Generate the new keys by a new PK key exchange (potentially also using the old keys and new random inputs). These all have different security properties and it's not clear to me which buckets these fall into. As far as complexity goes, 3 is more complicated than 2 which is more complicated than 1. -Ekr --001a11408592ee564e05280e8110 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 29, 2015 at 2:10 PM, Brian Smith <brian@briansmith.org<= /a>> wrote:
Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
OTO= H, you can't drop an attacker knowing older key without doing
new key exchange.

I think it wou= ld be very unfortunate to have the complexity of key update (the new keys a= re derived from the old keys) without having the benefits of rekeying (the = new keys are independent of the old keys).

Note: the keys here are *not* derived from the old = keys. Rather, they are derived via
a KDF from the same secret tha= t was used to generate the old keys. I.e.,

=C2=A0 = K_send_0 =3D KDF(MK_0, <label1>)
=C2=A0 K_recv_0 =3D KDF(MK= _0, <label2>)
=C2=A0 MK_1 =3D KDF(MK_0, <label3>)
=C2=A0 K_send_1 =3D KDF(MK_1, <label1>)
=C2=A0 K_rec= v_1 =3D KDF(MK_1, <label2>)


<= br>
Note that NIST Special Publication 800-133 [1] d= efines these separate terms, and I suggest we use them in this conversation= to avoid confusion:

Key update: A procedure in wh= ich a new cryptographic key is computed as a function of the (old) cryptographic key that it will replace.

Rekey:=C2=A0A procedure in which a new cryptographic key is= generated in a manner that is independent of the (old) cryptographic key that it will replace.=C2=A0

Hmm... It seems to me that there are three (at least) three separate possi= ble designs:

1. Generate the new keys by a new app= lication of the KDF with no additional inputs.
2. Generate the ne= w keys by a new application of the KDF with additional random inputs.
=
3. Generate the new keys by a new PK key exchange (potentially also us= ing the old
=C2=A0 =C2=A0 keys and new random inputs).
=
These all have different security properties and it's no= t clear to me which buckets
these fall into.

As far as complexity goes, 3 is more complicated than 2 which is m= ore complicated than 1.

-Ekr

<= /div>
--001a11408592ee564e05280e8110-- From nobody Tue Dec 29 12:10:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF091A892B for ; Tue, 29 Dec 2015 12:10:54 -0800 (PST) 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 a-nhs0CZqgXi for ; Tue, 29 Dec 2015 12:10:52 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4702F1A891D for ; Tue, 29 Dec 2015 12:10:52 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id f206so19724701wmf.0 for ; Tue, 29 Dec 2015 12:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:mime-version:content-type:in-reply-to:date:cc :message-id:references:to; bh=yrQnppABSE8QOtH1oXg4qSCaB1WFPdhywsL2jJB6Uhg=; b=cziLRoBIKhK2BfXq+blgJV3XiW4DNyVxyxdhn9mVqYz2Bpc/Y+a1b1VEidlg7AdPFy wcm95GyLgMUXAQgH3hrpx4EMPtM24uD1mx53oq8yKmhliCAYOa1q6sX3tzzOtNzK2gP5 Cs54JvUUf6vwAG3BVUenWBY1//bz9chViJlON2755zUZvBCgg0lyCZL0NZBQhoMJbhaT ZYfd5QmAALsVWmwuuMRTv/PIDfS0GS+VeaC0AtlAFESiqIfHPJOPj2lEg9PhfGgtbeqr +BMQ9QCiDLGmfNFOvrvArRMODEwqD+c2g/dmwdDHz+ijZ8uJPhVt6FKhtoWCAG2AtPP/ 2eYg== X-Received: by 10.28.230.74 with SMTP id d71mr47789995wmh.97.1451419850820; Tue, 29 Dec 2015 12:10:50 -0800 (PST) Received: from [192.168.0.103] (149-210-22-252.mobile.nym.cosmote.net. [149.210.22.252]) by smtp.gmail.com with ESMTPSA id 198sm22642617wml.22.2015.12.29.12.10.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 29 Dec 2015 12:10:50 -0800 (PST) From: Karthikeyan Bhargavan X-Google-Original-From: Karthikeyan Bhargavan Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FD04CA69-25D1-4CFB-B19D-EA75DD154352"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 In-Reply-To: Date: Tue, 29 Dec 2015 22:10:47 +0200 Message-Id: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> References: To: Brian Smith X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Dec 2015 20:10:54 -0000 --Apple-Mail=_FD04CA69-25D1-4CFB-B19D-EA75DD154352 Content-Type: multipart/alternative; boundary="Apple-Mail=_5387AD65-F93A-4CE1-83AE-06462C41E1CD" --Apple-Mail=_5387AD65-F93A-4CE1-83AE-06462C41E1CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As mentioned before, validating Curve25519 public values is necessary in = TLS 1.2 without session hash. Otherwise, as we pointed out in [1], the triple handshake attack = returns. [1] = http://www.internetsociety.org/doc/verified-contributive-channel-bindings-= compound-authentication = > On 29 Dec 2015, at 21:05, Brian Smith wrote: >=20 > On Tue, Dec 22, 2015 at 2:09 PM, Brian Smith > wrote: > If an implementation only implements ECDHE cipher suites then = implementing the session hash extension is not necessary, according to = RFC 7627. I believe there are also a few other factors that would = implementing the session hash extension to be unnecessary. >=20 > If checking that the shared value isn't zero is sufficient, and/or = blacklisting the public values that DJB mentions in [1] is sufficient, = either would be better than mandating the implementation of the session = hash extension just for this purpose. >=20 > Actually, the check for a result of zero is already required in the = current CFRG draft; see [1]. So, I think that the easiest way to fix the = TLS draft is to just delete the misleading text. >=20 > [1] https://tools.ietf.org/html/draft-irtf-cfrg-curves-11#section-6.1 = > Cheers, > Brian > -- > https://briansmith.org/ >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_5387AD65-F93A-4CE1-83AE-06462C41E1CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii As mentioned before, validating Curve25519 public values is = necessary in TLS 1.2 without session hash.
Otherwise, as = we pointed out in [1], the triple handshake attack returns.

[1] http://www.internetsociety.org/doc/verified-contributive-channe= l-bindings-compound-authentication

On = 29 Dec 2015, at 21:05, Brian Smith <brian@briansmith.org> wrote:

On Tue, = Dec 22, 2015 at 2:09 PM, Brian Smith <brian@briansmith.org> wrote:
If = an implementation only implements ECDHE cipher suites then implementing the session = hash extension is not necessary, according to RFC 7627. I = believe there are also a few other factors that would implementing the = session hash extension to be unnecessary.

If checking = that the shared value isn't zero is sufficient, and/or blacklisting the = public values that DJB mentions in [1] is sufficient, either would be = better than mandating the implementation of the session hash extension = just for this purpose.

Actually, the check for = a result of zero is already required in the current CFRG draft; see [1]. = So, I think that the easiest way to fix the TLS draft is to just delete = the misleading text.

[1] https://tools.ietf.org/html/draft-irtf-cfrg-curves-11#section-6= .1

Cheers,
Brian
--
https://briansmith.org/

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

= --Apple-Mail=_5387AD65-F93A-4CE1-83AE-06462C41E1CD-- --Apple-Mail=_FD04CA69-25D1-4CFB-B19D-EA75DD154352 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 iQEcBAEBCgAGBQJWgujHAAoJEB/WSo9veuUKhpEIAK+e/rK6M31/M2NyFLYZe2FJ uOcU1Qz8TZCMddNbbuiqhLgWALDlF/K1m1cEduqRcORsr0lpQlw79obtPBN8JyU/ DtJXUHOk/+1aDpbuJXsGjhlqW4byOFTE4fdspw0N/y2Y7Ft8/UU+Af6w1Xja+Bcz qcKGL/fbBh+rTdkQEGPdnmSzuzPii1DqrthTXH3sffpZHmB/gUYaclD1QDEEK3Io ONqdlM1sKHrqMGX2IkKL0/KM2C3ZowJty8pFAf7hi01NveTAKYUVXkZE0MBvf3DD QzLRDvIFHbzWJhQCZnOHU01WLdw59nKLOnummMg8who/w/0lSw/MaLZa4/KzU2c= =FTWG -----END PGP SIGNATURE----- --Apple-Mail=_FD04CA69-25D1-4CFB-B19D-EA75DD154352-- From nobody Tue Dec 29 14:08:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F2A1A8A59 for ; Tue, 29 Dec 2015 14:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 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, 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 9mNIfZsyrwiG for ; Tue, 29 Dec 2015 14:08:49 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C24E1A8A11 for ; Tue, 29 Dec 2015 14:08:49 -0800 (PST) Received: by mail-qg0-x22c.google.com with SMTP id 6so95541928qgy.1 for ; Tue, 29 Dec 2015 14:08:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=C3Y046vmu85X5H4ZYHuL79c72uO7JteL4hNJYARKB/4=; b=tMKrkRRKE80b3G2MqC4Nhvp4dULGJ760bsq+OW9EkwC6l+0pu9+4bqRfVj3bwyPLtr tK7WEuatP8S0UTCIgaBWl1vvnC/BiX0AHxXhhp+8SqrPMTUV+SoLnVhL+KcWR3KnKVbT C22qMJreF0h5T5EOsArIdwoD+EPYsegOFGo0gsaaPu1jFjhysYtf/MNqEp7q8hZNunXx BSjrA6gFeu4njVpOEW6sqVlviw0EZfxagYVghD4XlMmaTFpQNzolHd28G1am5QYJYodF Twxe4XLxICnWG/CaaJhGBqeXU5x+ziB4duTPdTIyOBJ41ddwuFpfKa4i9ttncPbX20Px CY/g== X-Received: by 10.140.92.35 with SMTP id a32mr80449518qge.92.1451426928702; Tue, 29 Dec 2015 14:08:48 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id m107sm29909450qgm.19.2015.12.29.14.08.47 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 29 Dec 2015 14:08:48 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Tue, 29 Dec 2015 17:08:46 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20151228205101.17780804.92503.42669@ll.mit.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201512291708.46892.davemgarrett@gmail.com> Archived-At: Cc: Florian Weimer Subject: Re: [TLS] Data volume 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: Tue, 29 Dec 2015 22:08:52 -0000 On Tuesday, December 29, 2015 02:10:25 pm Brian Smith wrote: > Note that NIST Special Publication 800-133 [1] defines these separate > terms, and I suggest we use them in this conversation to avoid confusion: >=20 > Key update: A procedure in which a new cryptographic key is computed as a > function of the (old) cryptographic key that it will replace. >=20 > Rekey: A procedure in which a new cryptographic key is generated in a > manner that is independent of the (old) cryptographic key that it will > replace. >=20 > [1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133.= pdf The current spec mostly uses the former, so yes, I guess we really should s= top saying "rekey" if this has been defined like this. The single use of "r= ekey" in the doc should probably be changed to "key update" if we keep thin= gs as-is, then. On Tuesday, December 29, 2015 02:33:38 pm Eric Rescorla wrote: > Note: the keys here are *not* derived from the old keys. Rather, they are= derived via > a KDF from the same secret that was used to generate the old keys. Yes, but they are derived from the same entropy as the old keys. Yes, that'= s not the same thing, but they're not totally independent new keys either. = If we're only doing this as a hack to fix ciphers that have problems (that = really should just be fixed instead), then this is fine. I think it's just = the fact that we _could_ add a full rekey mechanism without a fantastic amo= unt of additional effort is what's giving some people pause. If what we're really talking about is AES-GCM's data volume limits, what wo= uld be the best fix that just deals with precisely its issue, rather than d= oing a key update? > Hmm... It seems to me that there are three (at least) three separate > possible designs: >=20 > 1. Generate the new keys by a new application of the KDF with no addition= al inputs. > 2. Generate the new keys by a new application of the KDF with additional = random inputs. > 3. Generate the new keys by a new PK key exchange (potentially also using= the old > keys and new random inputs). >=20 > These all have different security properties and it's not clear to me whi= ch buckets > these fall into. >=20 > As far as complexity goes, 3 is more complicated than 2 which is more > complicated than 1. =46rom a certain perspective, doing a full new (EC)DHE with new randoms for= a full rekey is less of a change to the spec than a simple key update or s= omething in between. It is somewhat akin to a stripped-down version of rene= gotiation to just renegotiate the ephemeral key, but not any of the other p= arameters. I think it's worth considering, but I don't know if we absolutel= y need something here at all. Dave From nobody Tue Dec 29 15:11:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3111A8ABA for ; Tue, 29 Dec 2015 15:11:44 -0800 (PST) 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, HTML_MESSAGE=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 T3wFBDJnTu87 for ; Tue, 29 Dec 2015 15:11:43 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3FBC1A8AB9 for ; Tue, 29 Dec 2015 15:11:42 -0800 (PST) Received: by mail-yk0-x22c.google.com with SMTP id k129so119658036yke.0 for ; Tue, 29 Dec 2015 15:11:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GQPCyfng8xf8xZuwBhe2IrzF+ynrHwgOkZ4r0XW5C5Q=; b=NgyL4JIMaPov7SMVWZDEXgMOMUoyLlqY9sOJgAeTETCd5SqquaK8+B6Jp5Bze6HkzU XHmQHifoBA9SL9MYzHKB8KIdMQWUNiTecWT7sidnHlcHn5YXk4dippV0FliUWxP3Vv7z BtUHX0+D5LKNpYHdvKULyqRPsnS8NV8E2GwvOWPMtJ5nccQOEQIGoYXA67jJqPbinQLc uv0wGZp1ewG07CmYyGEc4Ppx/zoR2a5T7DE2FsSwu5d/kbTlBmeJ3csQzvORNMzAAhq7 RD+JBRAt1OlyBJlasVZNu58OkQyIor1y7OcYCHMdmR2DM31LuTSYC2Oj653vaSxwXh88 N69Q== 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=GQPCyfng8xf8xZuwBhe2IrzF+ynrHwgOkZ4r0XW5C5Q=; b=dYrbuB2tgX40oRVhG2b9IjzU422I6KWrq807elPhPglQZNtnn5EJDSRw8fISbMOWdP lZQuf0uYY3QCnVFO+3NuqrvUEBwSPeIL4y8M5KETYzHP050Z7jhCXhNJIVgBX0WpiX9U LSzNUKavYz8RLMNN8iUXJiWRaTY977Eeq09DbSRMBHDvgD+xIKoySSI4V9W+Wt5ZH8rg d9W5AOOKcNAMaehGDhpp4henAhGi3uuiQiTB+fmnOFPcUiswaSICskJulmG2iB+oBZqB quREhGl36Dx8QBEmGbv2vlOOdVsaQRRZgbEFCSvSRAiDm6Oxf9p5bjDnV6dB2Zp2G0Hu slHA== X-Gm-Message-State: ALoCoQnB9vi4OS/RzQubaJdvNeS3oyxyT/L5CIhvwnI/OZ1blPLijtKNhO9B50IbWxw2McPAaI6jCLSnShhBHqirEEAJr1udWA== X-Received: by 10.13.218.198 with SMTP id c189mr50466291ywe.165.1451430702266; Tue, 29 Dec 2015 15:11:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Tue, 29 Dec 2015 15:11:02 -0800 (PST) In-Reply-To: <201512291708.46892.davemgarrett@gmail.com> References: <20151228205101.17780804.92503.42669@ll.mit.edu> <201512291708.46892.davemgarrett@gmail.com> From: Eric Rescorla Date: Tue, 29 Dec 2015 18:11:02 -0500 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=94eb2c08192a6cf8ec0528118b52 Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Tue, 29 Dec 2015 23:11:44 -0000 --94eb2c08192a6cf8ec0528118b52 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 29, 2015 at 5:08 PM, Dave Garrett wrote: > On Tuesday, December 29, 2015 02:10:25 pm Brian Smith wrote: > > Note that NIST Special Publication 800-133 [1] defines these separate > > terms, and I suggest we use them in this conversation to avoid confusion: > > > > Key update: A procedure in which a new cryptographic key is computed as a > > function of the (old) cryptographic key that it will replace. > > > > Rekey: A procedure in which a new cryptographic key is generated in a > > manner that is independent of the (old) cryptographic key that it will > > replace. > > > > [1] > http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133.pdf > > The current spec mostly uses the former, so yes, I guess we really should > stop saying "rekey" if this has been defined like this. The single use of > "rekey" in the doc should probably be changed to "key update" if we keep > things as-is, then. Maybe. I don't find this taxonomy particularly evocative. > On Tuesday, December 29, 2015 02:33:38 pm Eric Rescorla wrote: > > Note: the keys here are *not* derived from the old keys. Rather, they > are derived via > > a KDF from the same secret that was used to generate the old keys. > > Yes, but they are derived from the same entropy as the old keys. Yes. I didn't say otherwise. > Yes, that's not the same thing, but they're not totally independent new > keys either. If we're only doing this as a hack to fix ciphers that have > problems (that really should just be fixed instead), then this is fine. I > think it's just the fact that we _could_ add a full rekey mechanism without > a fantastic amount of additional effort is what's giving some people pause. > Well, i don't know what "fantastic" means here, but we did look at this prior to designing the present mechanism and it was a nontrivial amount of additional complexity. -Ekr --94eb2c08192a6cf8ec0528118b52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 29, 2015 at 5:08 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Tuesd= ay, December 29, 2015 02:10:25 pm Brian Smith wrote:
> Note that NIST Special Publication 800-133 [1] defines these separate<= br> > terms, and I suggest we use them in this conversation to avoid confusi= on:
>
> Key update: A procedure in which a new cryptographic key is computed a= s a
> function of the (old) cryptographic key that it will replace.
>
> Rekey: A procedure in which a new cryptographic key is generated in a<= br> > manner that is independent of the (old) cryptographic key that it will=
> replace.
>
> [1] http://nvlpu= bs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133.pdf

The current spec mostly uses the former, so yes, I guess we really should s= top saying "rekey" if this has been defined like this. The single= use of "rekey" in the doc should probably be changed to "ke= y update" if we keep things as-is, then.

Maybe. I don't find this taxonomy particularly evocative.
=
=C2=A0
On Tuesday, December 29, 2015 02:33:38 pm Eric Rescorla wrote:
> Note: the keys here are *not* derived from the old keys. Rather, they = are derived via
> a KDF from the same secret that was used to generate the old keys.

Yes, but they are derived from the same entropy as the old keys.

Yes. I didn't say otherwise.
=C2=A0
Yes, that's not= the same thing, but they're not totally independent new keys either. I= f we're only doing this as a hack to fix ciphers that have problems (th= at really should just be fixed instead), then this is fine. I think it'= s just the fact that we _could_ add a full rekey mechanism without a fantas= tic amount of additional effort is what's giving some people pause.
=

Well, i don't know what "fantasti= c" means here, but we did look at this prior
to designing th= e present mechanism and it was a nontrivial amount of
additional = complexity.

-Ekr

<= /div> --94eb2c08192a6cf8ec0528118b52-- From nobody Tue Dec 29 16:20:43 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508441A8F35 for ; Tue, 29 Dec 2015 16:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 FW7rPBsuIWmE for ; Tue, 29 Dec 2015 16:20:39 -0800 (PST) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2767D1A8F33 for ; Tue, 29 Dec 2015 16:20:38 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id tBU0K18X000831; Tue, 29 Dec 2015 19:20:37 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Eric Rescorla , Dave Garrett Thread-Topic: [TLS] Data volume limits Thread-Index: AdFCl+LEde9nh48KlkmRxpLGJ4HFmw== Date: Wed, 30 Dec 2015 00:20:28 +0000 Message-ID: <20151230002037.17780804.91976.42860@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============0965585041==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2015-12-30_01:2015-12-29,2015-12-29,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1511060000 definitions=main-1512300003 Archived-At: Cc: Florian Weimer , "tls@ietf.org" Subject: Re: [TLS] Data volume 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: Wed, 30 Dec 2015 00:20:41 -0000 --===============0965585041== Content-Type: multipart/alternative; boundary="===============1055568378==" MIME-Version: 1.0 --===============1055568378== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SSBsaWtlIG9wdGlvbiAoMikgZnJvbSBFcmljJ3MgdGF4b25vbXkuCgpTZW50wqBmcm9twqBtecKg QmxhY2tCZXJyecKgMTDCoHNtYXJ0cGhvbmXCoG9uwqB0aGUgVmVyaXpvbsKgV2lyZWxlc3PCoDRH wqBMVEXCoG5ldHdvcmsuCkZyb206IEVyaWMgUmVzY29ybGEKU2VudDogVHVlc2RheSwgRGVjZW1i ZXIgMjksIDIwMTUgMTg6MTIKVG86IERhdmUgR2FycmV0dApDYzogRmxvcmlhbiBXZWltZXI7IHRs c0BpZXRmLm9yZwpTdWJqZWN0OiBSZTogW1RMU10gRGF0YSB2b2x1bWUgbGltaXRzCgoKCk9uIFR1 ZSwgRGVjIDI5LCAyMDE1IGF0IDU6MDggUE0sIERhdmUgR2FycmV0dCA8ZGF2ZW1nYXJyZXR0QGdt YWlsLmNvbT4gd3JvdGU6Ck9uIFR1ZXNkYXksIERlY2VtYmVyIDI5LCAyMDE1IDAyOjEwOjI1IHBt IEJyaWFuIFNtaXRoIHdyb3RlOgo+IE5vdGUgdGhhdCBOSVNUIFNwZWNpYWwgUHVibGljYXRpb24g ODAwLTEzMyBbMV0gZGVmaW5lcyB0aGVzZSBzZXBhcmF0ZQo+IHRlcm1zLCBhbmQgSSBzdWdnZXN0 IHdlIHVzZSB0aGVtIGluIHRoaXMgY29udmVyc2F0aW9uIHRvIGF2b2lkIGNvbmZ1c2lvbjoKPgo+ IEtleSB1cGRhdGU6IEEgcHJvY2VkdXJlIGluIHdoaWNoIGEgbmV3IGNyeXB0b2dyYXBoaWMga2V5 IGlzIGNvbXB1dGVkIGFzIGEKPiBmdW5jdGlvbiBvZiB0aGUgKG9sZCkgY3J5cHRvZ3JhcGhpYyBr ZXkgdGhhdCBpdCB3aWxsIHJlcGxhY2UuCj4KPiBSZWtleTogQSBwcm9jZWR1cmUgaW4gd2hpY2gg YSBuZXcgY3J5cHRvZ3JhcGhpYyBrZXkgaXMgZ2VuZXJhdGVkIGluIGEKPiBtYW5uZXIgdGhhdCBp cyBpbmRlcGVuZGVudCBvZiB0aGUgKG9sZCkgY3J5cHRvZ3JhcGhpYyBrZXkgdGhhdCBpdCB3aWxs Cj4gcmVwbGFjZS4KPgo+IFsxXSBodHRwOi8vbnZscHVicy5uaXN0Lmdvdi9uaXN0cHVicy9TcGVj aWFsUHVibGljYXRpb25zL05JU1QuU1AuODAwLTEzMy5wZGYK4oCOClRoZSBjdXJyZW50IHNwZWMg bW9zdGx5IHVzZXMgdGhlIGZvcm1lciwgc28geWVzLCBJIGd1ZXNzIHdlIHJlYWxseSBzaG91bGQg c3RvcCBzYXlpbmcgInJla2V5IiBpZiB0aGlzIGhhcyBiZWVuIGRlZmluZWQgbGlrZSB0aGlzLiBU aGUgc2luZ2xlIHVzZSBvZiAicmVrZXkiIGluIHRoZSBkb2Mgc2hvdWxkIHByb2JhYmx5IGJlIGNo YW5nZWQgdG8gImtleSB1cGRhdGUiIGlmIHdlIGtlZXAgdGhpbmdzIGFzLWlzLCB0aGVuLgoKTWF5 YmUuIEkgZG9uJ3QgZmluZCB0aGlzIHRheG9ub215IHBhcnRpY3VsYXJseSBldm9jYXRpdmUuCgrC oApPbiBUdWVzZGF5LCBEZWNlbWJlciAyOSwgMjAxNSAwMjozMzozOCBwbSBFcmljIFJlc2Nvcmxh IHdyb3RlOgo+IE5vdGU6IHRoZSBrZXlzIGhlcmUgYXJlICpub3QqIGRlcml2ZWQgZnJvbSB0aGUg b2xkIGtleXMuIFJhdGhlciwgdGhleSBhcmUgZGVyaXZlZCB2aWEKPiBhIEtERiBmcm9tIHRoZSBz YW1lIHNlY3JldCB0aGF0IHdhcyB1c2VkIHRvIGdlbmVyYXRlIHRoZSBvbGQga2V5cy4KClllcywg YnV0IHRoZXkgYXJlIGRlcml2ZWQgZnJvbSB0aGUgc2FtZSBlbnRyb3B5IGFzIHRoZSBvbGQga2V5 cy4KClllcy4gSSBkaWRuJ3Qgc2F5IG90aGVyd2lzZS4KCsKgClllcywgdGhhdCdzIG5vdCB0aGUg c2FtZSB0aGluZywgYnV0IHRoZXkncmUgbm90IHRvdGFsbHkgaW5kZXBlbmRlbnQgbmV3IGtleXMg ZWl0aGVyLiBJZiB3ZSdyZSBvbmx5IGRvaW5nIHRoaXMgYXMgYSBoYWNrIHRvIGZpeCBjaXBoZXJz IHRoYXQgaGF2ZSBwcm9ibGVtcyAodGhhdCByZWFsbHkgc2hvdWxkIGp1c3QgYmUgZml4ZWQgaW5z dGVhZCksIHRoZW4gdGhpcyBpcyBmaW5lLiBJIHRoaW5rIGl0J3MganVzdCB0aGUgZmFjdCB0aGF0 IHdlIF9jb3VsZF8gYWRkIGEgZnVsbCByZWtleSBtZWNoYW5pc20gd2l0aG91dCBhIGZhbnRhc3Rp YyBhbW91bnQgb2YgYWRkaXRpb25hbCBlZmZvcnQgaXMgd2hhdCdzIGdpdmluZyBzb21lIHBlb3Bs ZSBwYXVzZS4KCldlbGwsIGkgZG9uJ3Qga25vdyB3aGF0ICJmYW50YXN0aWMiIG1lYW5zIGhlcmUs IGJ1dCB3ZSBkaWQgbG9vayBhdCB0aGlzIHByaW9yCnRvIGRlc2lnbmluZyB0aGUgcHJlc2VudCBt ZWNoYW5pc20gYW5kIGl0IHdhcyBhIG5vbnRyaXZpYWwgYW1vdW50IG9mCmFkZGl0aW9uYWwgY29t cGxleGl0eS4KCi1Fa3IKCuKAjg== --===============1055568378== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable =
I like option (= 2) from Eric's taxonomy.
= =

= =
=
Sen= t from my BlackBerry 10 smartphone on th= e Verizon Wireless 4G LTE network.
= = =
=
From= : Eric Rescorla
Sent: Tuesday, December 29, 2015 18:12=
To: Dave Garrett
Cc: Florian Weimer; tls= @ietf.org
Subject: Re: [TLS] Data volume limits



On Tue, Dec 29, 2015 at 5:08 PM, Dave Garrett <davemgarrett@gmail.com>= ; wrote:
On Tuesday, December 29, 2015 02:10:25 pm Brian Smith wrote:
> Note that NIST Special Publication 800-133 [1] defines these separate<= br> > terms, and I suggest we use them in this conversation to avoid confusi= on:
>
> Key update: A procedure in which a new cryptographic key is computed a= s a
> function of the (old) cryptographic key that it will replace.
>
> Rekey: A procedure in which a new cryptographic key is generated in a<= br> > manner that is independent of the (old) cryptographic key that it will=
> replace.
>
> [1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133.pdf
=E2=80=8E
The current spec mostly uses the former, so yes, I guess we really should s= top saying "rekey" if this has been defined like this. The single use of "r= ekey" in the doc should probably be changed to "key update" if we keep thin= gs as-is, then.

Maybe. I don't find this taxonomy particularly evocative.

 
On Tuesday, December 29, 2015 02:33:38 pm Eric Rescorla wrote:
> Note: the keys here are *not* derived from the old keys. Rather, they = are derived via
> a KDF from the same secret that was used to generate the old keys.

Yes, but they are derived from the same entropy as the old keys.

Yes. I didn't say otherwise.

 
Yes, that's not the same thing, but they're not totally independent new key= s either. If we're only doing this as a hack to fix ciphers that have probl= ems (that really should just be fixed instead), then this is fine. I think = it's just the fact that we _could_ add a full rekey mechanism without a fantastic amount of additional effort= is what's giving some people pause.

Well, i don't know what "fantastic" means here, but we did look at thi= s prior
to designing the present mechanism and it was a nontrivial amount of
additional complexity.

-Ekr

=E2=80=8E
--===============1055568378==-- --===============0965585041== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKTM8n7QAAAABB0TANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE1MDYwNTE4MTY0NFoXDTE2MDYwNDE4MTY0NFowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDQ 0ZYk84x0NrbLSMf9w+9rvO8Z3d5dfpynEt9it4HkQ3Fht5wpD1DOICbdPmcuoNGv73LUI6oRn7XT CnAFOeW9dGZetOUBIL44l0BoMYlUOvqOhtXUIoxm6PNbnDsYW3HpNuiskGO+jjH5CrvSFsZ//GHA dMGsQpRNBU7ZHCoOZF7+rv9RUh5pN5OgKumv9p24nWtGHNR1AHHDjB50Df9/1DVGhpe6aqf5DBhe f+1rf/dgAhjFSzrj3lTgNuczkZcB9Xs6fktq1jRCuwCdVTXQ/xgM5I3FHnVP73QEccOFR9qfdEVA 5IT7jo/7hMIvOBMWUJGOP7BpYXJd4VKj8CxLAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUr3pideNu 8mmOhHY8C2sJnlo/HVAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAKVaDwP2SaWtXtIINTrHpvDXC9dslWAv Tfg3TmHrQMtlKM6GQqkgIzF4WMZgM64RyUOqEnXrDcD7a3GPrcf8zDjRnsTiYaGkzhEUb/do5igL Al5x+FwAvhwvEuLJwHpAk0sfbxfX4lxY1S1YUngS+5PXGJbbFaNPAOefDG8jGgaM4TJ1weWlLT8F /MJudL6L6azCfOWQZhxpnT037XWGPeUfuqNnmwkwwlrCQB2QYgLQJtlUZQPqnb8Y2hd6OfhE7qvv /fcvX7i+Q4UKh3xGlMN2QHoX0Sk9sxxc4vgJnKk7MhaufGtOuNJLZlSfzCQRGd9Zprq9M+ROXuwN u72bKQkwggTqMIID0qADAgECAgpMzyftAAAAAEHRMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTUwNjA1MTgxNjQ0WhcNMTYwNjA0MTgxNjQ0WjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANDRliTzjHQ2tstIx/3D72u87xnd3l1+nKcS32K3geRDcWG3nCkPUM4gJt0+Zy6g0a/v ctQjqhGftdMKcAU55b10Zl605QEgvjiXQGgxiVQ6+o6G1dQijGbo81ucOxhbcek26KyQY76OMfkK u9IWxn/8YcB0waxClE0FTtkcKg5kXv6u/1FSHmk3k6Aq6a/2nbida0Yc1HUAccOMHnQN/3/UNUaG l7pqp/kMGF5/7Wt/92ACGMVLOuPeVOA25zORlwH1ezp+S2rWNEK7AJ1VNdD/GAzkjcUedU/vdARx w4VH2p90RUDkhPuOj/uEwi84ExZQkY4/sGlhcl3hUqPwLEsCAwEAAaOCAbIwggGuMB0GA1UdDgQW BBSvemJ1427yaY6EdjwLawmeWj8dUDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEApVoPA/ZJpa1e0gg1Osem 8NcL12yVYC9N+DdOYetAy2UozoZCqSAjMXhYxmAzrhHJQ6oSdesNwPtrcY+tx/zMONGexOJhoaTO ERRv92jmKAsCXnH4XAC+HC8S4snAekCTSx9vF9fiXFjVLVhSeBL7k9cYltsVo08A558MbyMaBozh MnXB5aUtPwX8wm50vovprMJ85ZBmHGmdPTftdYY95R+6o2ebCTDCWsJAHZBiAtAm2VRlA+qdvxja F3o5+ETuq+/99y9fuL5DhQqHfEaUw3ZAehfRKT2zHFzi+AmcqTsyFq58a0640ktmVJ/MJBEZ31mm ur0z5E5e7A27vZspCTCCBO0wggPVoAMCAQICCihwejIAAAAALQcwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNTAxMjMxNzQ5MjlaFw0xNjAxMjMxNzQ5MjlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxfkXLPYTTuYb5RNGHpbanlxlFtbt0VTBuP9moOidhYHLDicTmcv5vuxX mHwqN12Kzasev9yGZg0mJZ9yZ8cz4qJw3GytkyfcQDqFpa1MpAIYFJfjwjvGoQ1eWHNLZjM3+TFw a7Lm9J1MiXg5MTlGNiHefA9VFc814fSr43PmQnAURaFYgIJ+zM557ryvGOZuy6K9aC1ksTTVMqff IAuBKXRy5wPMj9Vqpja9MfmLLIyYBIiH2RasfBr79jqrR2hRh4e2OvljliGVCzGgHPSSRKvHLZ7P ZhiEZXX9iTBXDbGoUCQ4YFLKZj+nNVs/Tq1MbIMJxkOX3iKvXP+GGWBGfwIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFEdIXm5OIutOt2J6RBFV8kFMn0hTMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQA4puc4 02/4d3mv+ugzTOsEpotU4vRdn9vwK3tmu2vRPyD135Xod/ZVRu7k2p3hCTEh8w5bZAeZOg2DL/7d vJ7UJtoyyPWnTMHHA5SkkdriA7IgO46HYk8W6i/2kYvlguMm1loV7s0m5DHrGsreUACqbiiwK+53 sH2WlsfMz51lNZ1mQWyUe3CyoFE2hIkLvzZQliBSSAvckYc3vikeNbyGvu54kJ1ADY6GAgrt9mfM YMYSuJEK+bXlFVDQ6Ao9Nse/NRhX8ApJ8abFhJveTljNYmlyghifHIoqLpRM5LGVKyB3SJiEmkFV fl3Zm3Hdzh+svHzZdZmXV5/LMTSXPv4NMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgpMzyftAAAAAEHRMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTIzMDAwMjAzNVowLwYJKoZIhvcNAQkEMSIEIBM0y92/u+H2 5IzdKB9nM2XGvj2sqEp3rxlbxd9GmgbZMAsGCSqGSIb3DQEBCwSCAQBnXc2FVpbwmtQZxqtKQogz M0OWIqzqpbyYNtx3SVZq9GHV8NsIoVeVQAHOVlQdYcJJsUhxcqkZXUn4lntkOKnim0NYtmiwWSnr XJkHMY2B4jKJd9F4dcJ2O9X4CyN/PWv+MbpTIGpmi+IrtDI1HHEQaveIKoibMXnu2Y7OKAM5Jczd DXzGvZa47aIlKVdLbF8eZPMXF4KDO7nX9+XS5bapmxCeOPM3twWvvFhfuIhwTPc1MGdIfcU39cRH 8s3IXJ3VL1K9a22n1yRo2D51+jLTMdfrwdas0uDXMl5iesBtENxvtiIo9QRpOPDxsrKDgMYney/S F2uzzQjgV3DAaGV/AAAAAAAA --===============0965585041==-- From nobody Wed Dec 30 02:30:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C6C1A1F04 for ; Wed, 30 Dec 2015 02:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 P4AmjX8s2J1Z for ; Wed, 30 Dec 2015 02:30:17 -0800 (PST) Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (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 2ACCB1A1EFD for ; Wed, 30 Dec 2015 02:30:17 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id D0552A8A1F8F; Wed, 30 Dec 2015 10:30:11 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 0BD7C1FE01C0; Wed, 30 Dec 2015 11:30:40 +0100 (CET) Date: Wed, 30 Dec 2015 11:30:40 +0100 From: Kurt Roeckx To: Brian Smith Message-ID: <20151230103040.GA6140@roeckx.be> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: Adam Langley , Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Dec 2015 10:30:19 -0000 On Tue, Dec 29, 2015 at 09:02:25AM -1000, Brian Smith wrote: > > Does that matter, though? The CFRG document doesn't allow the sender to set > the high bit to 1, right? In particular, it says "All calculations are > performed in GF(p), i.e., they are performed modulo p." and "For X25519, > the unused, most-significant bit MUST be zero." > > If the receiver can detect that the sender is non-conforming, then it > should be able to stop talking to it on that basis alone. I don't know enough about all the various draft to know if this might be a problem or not, but I'm concerned about providing an error oracle. Kurt From nobody Wed Dec 30 02:51:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42DF21A3B9C for ; Wed, 30 Dec 2015 02:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 ykyVSRewQIbO for ; Wed, 30 Dec 2015 02:51:43 -0800 (PST) Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (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 5CEAE1A21C3 for ; Wed, 30 Dec 2015 02:51:43 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 6D2D7A8A202E; Wed, 30 Dec 2015 10:51:38 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 8C50A1FE01C0; Wed, 30 Dec 2015 11:52:07 +0100 (CET) Date: Wed, 30 Dec 2015 11:52:07 +0100 From: Kurt Roeckx To: Karthikeyan Bhargavan Message-ID: <20151230105207.GB6140@roeckx.be> References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Dec 2015 10:51:44 -0000 On Tue, Dec 29, 2015 at 10:10:47PM +0200, Karthikeyan Bhargavan wrote: > As mentioned before, validating Curve25519 public values is necessary in TLS 1.2 without session hash. > Otherwise, as we pointed out in [1], the triple handshake attack returns. Would it make sense to have session hash as a requirement in TLS 1.2 when you want to use Curve25519? Kurt From nobody Wed Dec 30 03:10:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DA31AC3E5 for ; Wed, 30 Dec 2015 03:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 Qnb71RBjBn-n for ; Wed, 30 Dec 2015 03:10:55 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 443301A9251 for ; Wed, 30 Dec 2015 03:10:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 6B785173; Wed, 30 Dec 2015 13:10:53 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id Hwv4ASjssaB2; Wed, 30 Dec 2015 13:10:53 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 09F9A138; Wed, 30 Dec 2015 13:10:53 +0200 (EET) Date: Wed, 30 Dec 2015 13:10:51 +0200 From: Ilari Liusvaara To: Brian Smith Message-ID: <20151230111051.GA23341@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Dec 2015 11:10:57 -0000 On Tue, Dec 29, 2015 at 09:05:17AM -1000, Brian Smith wrote: > On Tue, Dec 22, 2015 at 2:09 PM, Brian Smith wrote: > > > If an implementation only implements ECDHE cipher suites then > > implementing the session hash extension is not necessary, according to RFC > > 7627. I believe there are also a few other factors that would implementing > > the session hash extension to be unnecessary. > > > > If checking that the shared value isn't zero is sufficient, and/or > > blacklisting the public values that DJB mentions in [1] is sufficient, > > either would be better than mandating the implementation of the session > > hash extension just for this purpose. > > > > Actually, the check for a result of zero is already required in the current > CFRG draft; see [1]. So, I think that the easiest way to fix the TLS draft > is to just delete the misleading text. The RFC4492bis draft already species that peer must abort on zero output. -Ilari From nobody Wed Dec 30 03:16:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384241AC410 for ; Wed, 30 Dec 2015 03:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 aZOwhZPVPT1r for ; Wed, 30 Dec 2015 03:16:34 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id CCB241AC40C for ; Wed, 30 Dec 2015 03:16:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id C3D0E1AD; Wed, 30 Dec 2015 13:16:32 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id LTzn04ZXtmkO; Wed, 30 Dec 2015 13:16:32 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 86900138; Wed, 30 Dec 2015 13:16:32 +0200 (EET) Date: Wed, 30 Dec 2015 13:16:31 +0200 From: Ilari Liusvaara To: Kurt Roeckx Message-ID: <20151230111631.GB23341@LK-Perkele-V2.elisa-laajakaista.fi> References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20151230105207.GB6140@roeckx.be> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: Karthikeyan Bhargavan , "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Dec 2015 11:16:36 -0000 On Wed, Dec 30, 2015 at 11:52:07AM +0100, Kurt Roeckx wrote: > On Tue, Dec 29, 2015 at 10:10:47PM +0200, Karthikeyan Bhargavan wrote: > > As mentioned before, validating Curve25519 public values is necessary in TLS 1.2 without session hash. > > Otherwise, as we pointed out in [1], the triple handshake attack returns. > > Would it make sense to have session hash as a requirement in TLS > 1.2 when you want to use Curve25519? I don't think that is reasonable. The RFC4492bis document could point out the consequences of omitting the zero check (which is already REQUIRED) in the security considerations tho. -Ilari From nobody Wed Dec 30 14:55:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B009C1B29E7 for ; Wed, 30 Dec 2015 14:55:12 -0800 (PST) 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 r8pguFUr-61P for ; Wed, 30 Dec 2015 14:55:11 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9081B29E6 for ; Wed, 30 Dec 2015 14:55:11 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id 77so52285377ioc.2 for ; Wed, 30 Dec 2015 14:55:11 -0800 (PST) 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=SczE7ACTkaFbSjzEREQRpZMj7vQF6jLDuz7e5CbQud0=; b=P8D5Fqki635RVfARtiC9pDDUHkLYpqDVMDPZI0CjH6P8i9YJZtoCJr9qEjuFMXmK4G y81uV7fMB2JWYy6/FO4jTuQy8yAcYZcudFmn7fB+PyUoJ85aksHV8WQgV/kde9u/VCv7 dM7WnX5VXLM99W7CA3BkytZeG+Js+K089SSLDfeN3UH1CvQNEus/Cxri93d2OnweWWps 2gtkwbPP36+JPrnWIg3wIZb0c5JCzYec+XEQ3XTgerXWx/8iphZWfj5pWHXrIrZqbI/o N9ZnbFZ0VKedTaqvGEgFezdOZIpmR9UhnXkdCo7Gl9FxgHDwsLt4zoCfJX6wfdMtY86G Kl/g== MIME-Version: 1.0 X-Received: by 10.107.33.12 with SMTP id h12mr10860822ioh.108.1451516110695; Wed, 30 Dec 2015 14:55:10 -0800 (PST) Received: by 10.36.149.130 with HTTP; Wed, 30 Dec 2015 14:55:10 -0800 (PST) In-Reply-To: <20151230111631.GB23341@LK-Perkele-V2.elisa-laajakaista.fi> References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> <20151230111631.GB23341@LK-Perkele-V2.elisa-laajakaista.fi> Date: Thu, 31 Dec 2015 09:55:10 +1100 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Karthikeyan Bhargavan , "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Dec 2015 22:55:12 -0000 On 30 December 2015 at 22:16, Ilari Liusvaara wrote: >> Would it make sense to have session hash as a requirement in TLS >> 1.2 when you want to use Curve25519? > > I don't think that is reasonable. I think that is entirely reasonable. TLS 1.2 relies on contributory behaviour. 25519 doesn't provide that unless you do some extra checking that we know many implementations don't do. I'd be OK with either requiring session hash, some checking of values, or both. Otherwise we create a situation where the shared secret can be forced by an attacker. From nobody Wed Dec 30 15:04:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B0B1B29ED for ; Wed, 30 Dec 2015 15:04:11 -0800 (PST) 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, 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 eYnWhUAE61Ro for ; Wed, 30 Dec 2015 15:04:10 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64E751B29EB for ; Wed, 30 Dec 2015 15:04:10 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id o124so208791756oia.1 for ; Wed, 30 Dec 2015 15:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T6+7/gzwWlhOVHbYBxkkSRFoDVctJIMdgCndhAn6SMI=; b=G7IOn0l48Y1LFjY5elYtJVzzsJwxJki6SVir9OCG7PyIxq9nQIblHxCoHEoYaUySPx V2mtRjDhqaZ3IPbwvXMkkIbCrEXaLGLtwA7Qsf0ZI89p1RQjNFWykcgoNl+CSDRUnO+d Ou5VTQw5l7hOM6tCKf+jGkCtPh57CXpFWT1IkZ9SItTJdHpvQMcgxL46UmiFtcB2UO0W J0JV2AammWSjnMSa510TrfurysIzHt5VsQP60H/Pt2QrBGNbdXqZdEss6fQFjFUbQI9n wLJJ2wGzuW28R2FHcslukyU1hNx7TzzCRKLYp1lTNLgXMuT8OjNCU/noTRYB63QDcuWr Xzow== 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=T6+7/gzwWlhOVHbYBxkkSRFoDVctJIMdgCndhAn6SMI=; b=Kbmh0qR7Wl8yEh3OdK40e8i3iGHoAfCZno8ZBlLDtnFhwzOxAVSXubaGLignWyjnxD FnjAQ3hqlakqnFhqT+SbVNIISVQgG9wI/vfipJJl3AVwESj5wn1NOB6xTMM1YBTZZdIX SAN5/kaSGRRjb3iFxPUvyMME14DW4TDhJUTtvafmUYOSJDLj1YYlePEcUALw8oKXjQsB 0BSu8AGfbox/owTtvXSv70ru+TmXnsN+gelRj/WLxRGJR7M1Gc9Bp6yZBVzl/TbAnTX1 z1g0HJlEnqIYnurNkYDtiF4qySTDE0rV7T2dDKtG/BUXTlBDGwdKXSmFzWCfvGgsTaNF iAXw== X-Gm-Message-State: ALoCoQmKSTuovpYuAuVOoWM6TfLuT26UI1WAR9zWPpVM4Nopsi0Jh9zvvYIFm0K/Ah5ZdGNpzhXIbXYla+WwBbP+8RyzlSXrIg== MIME-Version: 1.0 X-Received: by 10.202.186.198 with SMTP id k189mr41849665oif.105.1451516649654; Wed, 30 Dec 2015 15:04:09 -0800 (PST) Received: by 10.76.62.8 with HTTP; Wed, 30 Dec 2015 15:04:09 -0800 (PST) In-Reply-To: <20151230103040.GA6140@roeckx.be> References: <20151230103040.GA6140@roeckx.be> Date: Wed, 30 Dec 2015 13:04:09 -1000 Message-ID: From: Brian Smith To: Kurt Roeckx Content-Type: multipart/alternative; boundary=001a113cd2b049effd0528258e97 Archived-At: Cc: Adam Langley , Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Dec 2015 23:04:12 -0000 --001a113cd2b049effd0528258e97 Content-Type: text/plain; charset=UTF-8 Kurt Roeckx wrote: > On Tue, Dec 29, 2015 at 09:02:25AM -1000, Brian Smith wrote: > > > > Does that matter, though? The CFRG document doesn't allow the sender to > set > > the high bit to 1, right? In particular, it says "All calculations are > > performed in GF(p), i.e., they are performed modulo p." and "For X25519, > > the unused, most-significant bit MUST be zero." > > > > If the receiver can detect that the sender is non-conforming, then it > > should be able to stop talking to it on that basis alone. > > I don't know enough about all the various draft to know if this > might be a problem or not, but I'm concerned about providing an > error oracle. > It's a public value sent by the other side, so that's not an issue. Cheers, Brian -- https://briansmith.org/ --001a113cd2b049effd0528258e97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Kurt= Roeckx <kurt@roeckx.be> wrote:
On Tue, Dec 29, 2015 at 09:02:25AM -1000, Brian Smith w= rote:
>
> Does that matter, though? The CFRG document doesn't allow the send= er to set
> the high bit to 1, right? In particular, it says "All calculation= s are
> performed in GF(p), i.e., they are performed modulo p." and "= ;For X25519,
> the unused, most-significant bit MUST be zero."
>
> If the receiver can detect that the sender is non-conforming, then it<= br> > should be able to stop talking to it on that basis alone.

I don't know enough about all the various draft to know if this<= br> might be a problem or not, but I'm concerned about providing an
error oracle.

It's a public value s= ent by the other side, so that's not an issue.

Cheers,
Brian
--
<= div dir=3D"ltr">
--001a113cd2b049effd0528258e97-- From nobody Wed Dec 30 15:54:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F9E1A00A5 for ; Wed, 30 Dec 2015 15:54:29 -0800 (PST) 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, 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 1iTeW1VqrlPU for ; Wed, 30 Dec 2015 15:54:28 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50EA81A0095 for ; Wed, 30 Dec 2015 15:54:28 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id o62so204071265oif.3 for ; Wed, 30 Dec 2015 15:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l+ZASjzKBTzhihhz9kk1KUzNMbKkwXAtbYmhm1dhB5c=; b=Te3vNiQ3COYELRaQBOPVpo/eVRlw0zfFsuTN3D2vLgbjMKwaXbTFmu2HJJYdZ4Ujo0 Qfc32L+b2mnqssAntUP3swPodVbkqvZki+8AUwawUHAGbl8k3y7Iz8BGFn5Hyr/JCjBC nWHFtqMBhiDaLMv7yeOp3RG/qLPFP/BV4kO3qrHrjgqpuUFVrgeTBwIZWxk4T8fRrEuC qin+kVVXh4LEy//35F3cFQvbG23XGfBnAsKQyco5RseqJc1Fi2uY+qC5AzdVkqMC5XJH U/7Xzj4qJG9OUF1QUTLESMAkkOg8hXP0qcBWMlIyzHNFMmVwCa4B7Quk1wRz/U+puu7H T5fw== 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=l+ZASjzKBTzhihhz9kk1KUzNMbKkwXAtbYmhm1dhB5c=; b=lfkEOSo24TDMo0wHbP+3ccIvFnTphoUdmaRZujuZ4ZLkLLpfmGh0LYf7D/xZyjzuVD g2Z9HrpUY1mq6ZbBL0oT27xZ3jFdNHjhQLwHzm2KOft1lCNc13hva5+EaGgE0xhmmXFI mufJMrSBpq59GwjYDY3pqf5/BWzsv/bamfkAvKmT2pn9/6VNijtxTBkoy2cUTXgWRb2E CQzxKLl3Lp4Q8xGWJuAWPbtbT6ST/gBjUsFTQvxSDMnWjE4jxLsuxV6BpXgury4thcs6 DCcCeHZNKSuyG65+/bfW5vnks+IP6UgQ+CdDTMkhySgnaX2gHzh+U7JXoxTDAchso3rD XUJw== X-Gm-Message-State: ALoCoQk1BD7nlNov2QUlCd90RPHtccr2H3QPx1OjvAL5EkbTqO/6LyN4zdAY8UFP01/MEUtP0BFY8SEpUJb9lHJdPEV374ZvvA== MIME-Version: 1.0 X-Received: by 10.202.60.195 with SMTP id j186mr40893188oia.70.1451519667641; Wed, 30 Dec 2015 15:54:27 -0800 (PST) Received: by 10.76.62.8 with HTTP; Wed, 30 Dec 2015 15:54:27 -0800 (PST) In-Reply-To: References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> <20151230111631.GB23341@LK-Perkele-V2.elisa-laajakaista.fi> Date: Wed, 30 Dec 2015 13:54:27 -1000 Message-ID: From: Brian Smith To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113cd33c2cd0ee0528264276 Archived-At: Cc: Karthikeyan Bhargavan , "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Dec 2015 23:54:30 -0000 --001a113cd33c2cd0ee0528264276 Content-Type: text/plain; charset=UTF-8 Martin Thomson wrote: > On 30 December 2015 at 22:16, Ilari Liusvaara > wrote: > >> Would it make sense to have session hash as a requirement in TLS > >> 1.2 when you want to use Curve25519? > > > > I don't think that is reasonable. > > I think that is entirely reasonable. TLS 1.2 relies on contributory > behaviour. 25519 doesn't provide that unless you do some extra > checking that we know many implementations don't do. > The check for zero is not "extra". It is required by the CFRG draft spec. Here's my proposed rewrite of this section: 2.3. Public key validation draft-irtf-cfrg-curves-11 specifies how to do the Diffie-Hellman computation and the checks that are required. Note in particular that [I-D.irtf-cfrg-curves Section 6.1] and [I-D.irtf-cfrg-curves Section 6.2] require implementations to check, in a side-channel-safe manner, that the result of the Diffie-Hellman computation is non-zero. Such a check is essential for preventing key dictation attacks in TLS, as described in [Contributive Section III.b.3]. Implementations MAY check that the peer's public value u-coordinate is on the curve, but such a check is not necessary when the check for a non-zero result is done. The practical consequence of this is that public u-coordinates must be reduced modulo the field order as required in draft-irtf-cfrg-curves-11 before being transmitted. [Contributive] Bhargavan, K, A. Delignat-Lavaud, and A. Pironti. "Verified Contributive Channel Bindings for Compound Authentication", Feb 2015, . I am not sure if [Contributive] is the best reference, but it is the only one I know of that actually addresses the issue specifically for TLS and these curves. Cheers, Brian -- https://briansmith.org/ --001a113cd33c2cd0ee0528264276 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Thomson <martin.thomson@gmail.com> wrote:
On 30 December 2015 at 22:16, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
>> Would it make sense to have session hash as a requirement in TLS >> 1.2 when you want to use Curve25519?
>
> I don't think that is reasonable.

I think that is entirely reasonable.=C2=A0 TLS 1.2 relies on contrib= utory
behaviour.=C2=A0 25519 doesn't provide that unless you do some extra checking that we know many implementations don't do.

The check for zero is not "extra". It is requir= ed by the CFRG draft spec.

Here's my proposed = rewrite of this section:


2.3.= =C2=A0 Public key validation

=C2=A0 =C2=A0draft-ir= tf-cfrg-curves-11 specifies how to do the Diffie-Hellman
=C2=A0 = =C2=A0computation and the checks that are required.
=C2=A0 =C2=A0=
=C2=A0 =C2=A0Note in particular that [I-D.irtf-cfrg-curves Secti= on 6.1] and
=C2=A0 =C2=A0[I-D.irtf-cfrg-curves Section 6.2] requi= re implementations to
=C2=A0 =C2=A0check, in a side-channel-safe = manner, that the result of the
=C2=A0 =C2=A0Diffie-Hellman comput= ation is non-zero. Such a check is essential
=C2=A0 =C2=A0for pre= venting key dictation attacks in TLS, as described in
=C2=A0 =C2= =A0[Contributive Section III.b.3].
=C2=A0 =C2=A0
=C2=A0= =C2=A0Implementations MAY check that the peer's public value u-coordin= ate
=C2=A0 =C2=A0is on the curve, but such a check is not necessa= ry when the check
=C2=A0 =C2=A0for a non-zero result is done. The= practical consequence of this is
=C2=A0 =C2=A0that public u-coor= dinates must be reduced modulo the field order
=C2=A0 =C2=A0as re= quired in draft-irtf-cfrg-curves-11 before being transmitted.
[Contributive]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Bhargavan, K, A. Delignat-Lavaud, and A. Pironti. "Verified
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Contributive Channel Bindin= gs for Compound Authentication",
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0Feb 2015,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= <https://www.internetsociety.org/sites/default/files/08_5.pdf>.

I am not sure if [Contributive] is the best ref= erence, but it is the only one I know of that actually addresses the issue = specifically for TLS and these curves.

Cheers,
Brian
--
--001a113cd33c2cd0ee0528264276-- From nobody Wed Dec 30 16:03:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD671A00B9 for ; Wed, 30 Dec 2015 16:03:52 -0800 (PST) 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, 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 Ys6c5H2aouuz for ; Wed, 30 Dec 2015 16:03:51 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A5191A00B8 for ; Wed, 30 Dec 2015 16:03:51 -0800 (PST) Received: by mail-ob0-x22b.google.com with SMTP id wp13so53072597obc.1 for ; Wed, 30 Dec 2015 16:03:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2jPB//NcWUf80/kfzUSIvfVkihUDDnM4RCUeSvWpCbA=; b=gw5YNw2ta8BmOvpsLxb0Ft7gBpsNs0l4pzUhIZEDdKlqPY5FTaZ/O86oP57qUJCYTd lvxMaABZsixuk3QpRstqo7aYPhfdpuwR2ShijpscfImzHp7OK0lQRRZgVLkgEG4lyWSK dTYumimKBMK8iPNwsLVX0Xa7XdHcgeepdu4cOF+T6GCq6Q0k6TzgO3kLjbJZYBrGV2AH 4JNrTNqNqc+F6KnYF8Zu3jlYXlWN7GT7z4j3a71Qpa/r21lxRpsB71FhpULkLp/2ZHwh Q16/DUSojMCevSVUMXnU7mjlzBMAq/2BpPhg5KmFLZCE6zVRsOwbBbDAJVwbG2GfsZ6J eD7A== 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=2jPB//NcWUf80/kfzUSIvfVkihUDDnM4RCUeSvWpCbA=; b=WKdDrTciFGfJ8lhNBHsNfoaFUcDWKPTnKHlTZsQpgEe2H+6s+dOayZExsp5A07+upA iHq3P3xS/c5EcH4ixOcKWNBTYNDSJzQKtF6Pf3JZ3E4Bj6yD2YSu+7/Xt6mRrfnqXDf1 w1mSIhKlSjt+MWHWR3rUDKU/O+q0LMpY51limqJv1y+AWB2S7vNqK7XuaYfzlKriwlcZ KRWTKDxfOnPFLCfbmmjpaLKwa+Z6juVAxVwkXgra66Ret9Del+HdZTR/rUWdjuvzrOl9 mHDpWPoYSsBSzmC03udCNezQVNuLKedtvVCw1omAmnAF2dlFrv2O8xbMgIu1vbQrC3Mk +/6A== X-Gm-Message-State: ALoCoQkKXpV9ZZ3CiHXoAoIMfmzgV0Ip9bD9wQwlX9BAMzvsZezQpawf3InfmTOOdTPvBXtuxm/fGwdNJDHZCZrxvuMWfOd5Vw== MIME-Version: 1.0 X-Received: by 10.182.130.234 with SMTP id oh10mr44716753obb.58.1451520230821; Wed, 30 Dec 2015 16:03:50 -0800 (PST) Received: by 10.76.62.8 with HTTP; Wed, 30 Dec 2015 16:03:50 -0800 (PST) In-Reply-To: <20151230105207.GB6140@roeckx.be> References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> Date: Wed, 30 Dec 2015 14:03:50 -1000 Message-ID: From: Brian Smith To: Kurt Roeckx Content-Type: multipart/alternative; boundary=089e013a0112be3101052826637b Archived-At: Cc: Karthikeyan Bhargavan , "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 00:03:52 -0000 --089e013a0112be3101052826637b Content-Type: text/plain; charset=UTF-8 Kurt Roeckx wrote: > On Tue, Dec 29, 2015 at 10:10:47PM +0200, Karthikeyan Bhargavan wrote: > > As mentioned before, validating Curve25519 public values is necessary in > TLS 1.2 without session hash. > > Otherwise, as we pointed out in [1], the triple handshake attack returns. > > Would it make sense to have session hash as a requirement in TLS > 1.2 when you want to use Curve25519? > I think it is a good idea to implement the session hash extension, in general. However, I think it is a bad idea to prescribe it as the solution for this particular problem because: 1. draft-irtf-cfrg-curves-11, in sections 6.1 and section 6.2 already require the check for a non-zero result, and that check is sufficient. 2. It is easy to make an automated test that verifies that an X25519/X448 implementation implements the non-zero check. Adding an automated test for conditional enabling of them based on the presence of the session hash extension is much harder. 3. It is much less error-prone to implement the non-zero result check than to make the availability of X25519/X448 depend on whether or not the session hash extension is implemented. Experience, e.g. [1], has shown that such conditional enabling is error-prone. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=919677 Cheers, Brian -- https://briansmith.org/ --089e013a0112be3101052826637b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Kurt= Roeckx <kurt@roeckx.be> wrote:
On Tu= e, Dec 29, 2015 at 10:10:47PM +0200, Karthikeyan Bhargavan wrote:
> As mentioned before, validating Curve25519 public values is necessary = in TLS 1.2 without session hash.
> Otherwise, as we pointed out in [1], the triple handshake attack retur= ns.

Would it make sense to have session hash as a requirement in TLS
1.2 when you want to use Curve25519?

I = think it is a good idea to implement the session hash extension, in general= . However, I think it is a bad idea to prescribe it as the solution for thi= s particular problem because:

1.=C2=A0draft-irtf-c= frg-curves-11, in sections 6.1 and section 6.2 already require the check fo= r a non-zero result, and that check is sufficient.

2. It is easy to make an automated test that verifies that an X25519/X448 = implementation implements the non-zero check. Adding an automated test for = conditional enabling of them based on the presence of the session hash exte= nsion is much harder.

3. It is much less error-pro= ne to implement the non-zero result check than to make the availability of = X25519/X448 depend on whether or not the session hash extension is implemen= ted. Experience, e.g. [1], has shown that such conditional enabling is erro= r-prone.


Cheers,
--089e013a0112be3101052826637b-- From nobody Wed Dec 30 16:08:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52AB71A00DC for ; Wed, 30 Dec 2015 16:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 jL1i2faqSnle for ; Wed, 30 Dec 2015 16:08:07 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 53E4C1A00D5 for ; Wed, 30 Dec 2015 16:08:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id B0FB0224E; Thu, 31 Dec 2015 02:08:05 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 0XGGY9CQ_bpV; Thu, 31 Dec 2015 02:08:05 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 27F9427F; Thu, 31 Dec 2015 02:08:05 +0200 (EET) Date: Thu, 31 Dec 2015 02:08:03 +0200 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20151231000803.GA23937@LK-Perkele-V2.elisa-laajakaista.fi> References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> <20151230111631.GB23341@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: Karthikeyan Bhargavan , "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 00:08:09 -0000 On Thu, Dec 31, 2015 at 09:55:10AM +1100, Martin Thomson wrote: > On 30 December 2015 at 22:16, Ilari Liusvaara wrote: > >> Would it make sense to have session hash as a requirement in TLS > >> 1.2 when you want to use Curve25519? > > > > I don't think that is reasonable. > > I think that is entirely reasonable. TLS 1.2 relies on contributory > behaviour. 25519 doesn't provide that unless you do some extra > checking that we know many implementations don't do. > > I'd be OK with either requiring session hash, some checking of values, > or both. Otherwise we create a situation where the shared secret can > be forced by an attacker. The draft already has the checks. I also think I figured out a way to truly force contributory behaviour without any checks: It is a bit nasty hack: Throw the exchange keys into the PMS, expanding it from 32/56 bytes to 96/168 bytes. -Ilari From nobody Wed Dec 30 16:09:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BDD1A00D8 for ; Wed, 30 Dec 2015 16:09:14 -0800 (PST) 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, 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 00YorE8wJHPd for ; Wed, 30 Dec 2015 16:09:13 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605181A0078 for ; Wed, 30 Dec 2015 16:09:13 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id y66so209654014oig.0 for ; Wed, 30 Dec 2015 16:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=wJ5GArUtFDNK/0skPHzS9gqGo31QmEJd43rLegJ4VzY=; b=WzhDt3v0et8Gipf9AnUm3EGUnykC5oZ7zaFG6+5I3Pwox4PR9Y7rsyrYElf1+kBhIJ Y3QgZ9cMMQlLK46U6XsldZbRfnYKsBI+NYpSacP9P3Y/QTon0wl8vaizNcFDt3k0seyt niZb0je0qigBFogWHSWrA1FK/JjfkGmlwMY3gb06kAiqDXofmtb7SqbPKhdFvjAjDjZE aHtCpNpLIVDWAAvXvOCNh7qwjIKoutMMbi88jjsHS5Pqd8pGR+V2Q4vGeXa0WGOTjMUH xxNqICyJaRmzwjdR5Kus+aP4zpTxx6Xg81zpq7D6xqS5S8rYsdflmRpsnTOVwLMDQpCK KM9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=wJ5GArUtFDNK/0skPHzS9gqGo31QmEJd43rLegJ4VzY=; b=CLQB8zjgcHQ+BFCNAtFEbu1ghzoAycLffVf/c86edi3NPOnyFBCOXTXvEzgiR40nxM mfakzpN9hGCvvfIAO4aacDWwixmHQbaEfStBZCblrWVDuySjiDCxTXX5IW/fMGk/ADyz Fwebk3wRhS0I3qGjCW6/4HVq0+Noe+NOQnNq/r1eJ2tg/CZ/7zGccWUm8WtTGuHrhNAJ riaFDC6CfNd1QE0SpCp2ryy3TsNL9aZKw9nRmCzO1WqdQ4eVQk5OoQ2pSjzO5lGCkTW8 2C3jaYdfvoFkt/HJngk96h3Qxn8DOCnBnw492maTrgOl2NY9aYSF5V0Yx9AKR4/SgqG0 1SCA== X-Gm-Message-State: ALoCoQmvC3VmH0hoda9+f1I2JaFCJZGlC9g5rCEz7GQchC3/dgKgZJCUtj8SnG5WlxKm+Qm8ETmQ6gjdSW9qQ9W+v02AELwHOA== MIME-Version: 1.0 X-Received: by 10.202.90.66 with SMTP id o63mr41078564oib.129.1451520552839; Wed, 30 Dec 2015 16:09:12 -0800 (PST) Received: by 10.76.62.8 with HTTP; Wed, 30 Dec 2015 16:09:12 -0800 (PST) Date: Wed, 30 Dec 2015 14:09:12 -1000 Message-ID: From: Brian Smith To: "" Content-Type: multipart/alternative; boundary=001a113d5da8efc23f05282676be Archived-At: Subject: [TLS] draft-ietf-tls-curve25519: Remove Appendix A X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 00:09:14 -0000 --001a113d5da8efc23f05282676be Content-Type: text/plain; charset=UTF-8 I suggest that the entire Appendix A be removed, as it duplicates draft-irtf-cfrg-curves-11 and it is too difficult and tedious to verify that it matches what draft-irtf-cfrg-curves-11 says. Also, it doesn't say anything about X448. I've noticed that the draft has a few other places that talk specifically about Curve25519 or X25519 where instead it should talk more generally about both the curves in draft-irtf-cfrg-curves-11. These should be cleared up too. Cheers, Brian -- https://briansmith.org/ --001a113d5da8efc23f05282676be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I suggest that the entire Appendix A be removed, as it dup= licates draft-irtf-cfrg-curves-11 and it is too difficult and tedious to ve= rify that it matches what=C2=A0draft-irtf-cfrg-curves-11 says.

Also, it doesn't say anything about X448. I've noticed that = the draft has a few other places that talk specifically about Curve25519 or= X25519 where instead it should talk more generally about both the curves i= n=C2=A0draft-irtf-cfrg-curves-11. These should be cleared up too.
=

Cheers,
--001a113d5da8efc23f05282676be-- From nobody Wed Dec 30 16:23:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932C91A0119 for ; Wed, 30 Dec 2015 16:23:15 -0800 (PST) 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 4f6O_gBdPKuS for ; Wed, 30 Dec 2015 16:23:14 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78531A0115 for ; Wed, 30 Dec 2015 16:23:13 -0800 (PST) Received: by mail-yk0-x22f.google.com with SMTP id v14so75616659ykd.3 for ; Wed, 30 Dec 2015 16:23:13 -0800 (PST) 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=Ofvn0WCRWG6ewTp7lHDdCbhkAuH3/VtCi55XBbJsYsQ=; b=xaurlql1zh/ajrzgLcjfkz2k777KEeww97U/YmKZaRbIKp8gOPpW1xWq3b7xnoXfe0 Rdcr6efcSULCU28Ice8Gq2DhIZmBuuMESEIQhpH9PcVARhnMgh0MXopu3KE0NY9ophau wNuDtdvG/5eaSMWgDsDbBniIu0PSWIrBS9TQWpD56nChcfl+G36bg9N3XeNxh8Pjnp9+ DgdwGqhXvDj6PiTlIr+EhAbm/FOLjAz/7SlTVcWj5P0oW1AkgPhk2NAZBmTrvFvviFSB hXQ5r+2lk9n/AgCgSuNhMbVex8DX+ZUsMu0xWuo4kuO5qTuxnOjPHchXSKnCYEgBaqAR Hcww== MIME-Version: 1.0 X-Received: by 10.129.123.134 with SMTP id w128mr27668865ywc.345.1451521393146; Wed, 30 Dec 2015 16:23:13 -0800 (PST) Received: by 10.13.216.150 with HTTP; Wed, 30 Dec 2015 16:23:12 -0800 (PST) Received: by 10.13.216.150 with HTTP; Wed, 30 Dec 2015 16:23:12 -0800 (PST) In-Reply-To: <20151231000803.GA23937@LK-Perkele-V2.elisa-laajakaista.fi> References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> <20151230111631.GB23341@LK-Perkele-V2.elisa-laajakaista.fi> <20151231000803.GA23937@LK-Perkele-V2.elisa-laajakaista.fi> Date: Wed, 30 Dec 2015 19:23:12 -0500 Message-ID: From: Watson Ladd To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1144fe5205c4c5052826a977 Archived-At: Cc: Karthikeyan Bhargavan , "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 00:23:15 -0000 --001a1144fe5205c4c5052826a977 Content-Type: text/plain; charset=UTF-8 On Dec 30, 2015 7:08 PM, "Ilari Liusvaara" wrote: > > On Thu, Dec 31, 2015 at 09:55:10AM +1100, Martin Thomson wrote: > > On 30 December 2015 at 22:16, Ilari Liusvaara wrote: > > >> Would it make sense to have session hash as a requirement in TLS > > >> 1.2 when you want to use Curve25519? > > > > > > I don't think that is reasonable. > > > > I think that is entirely reasonable. TLS 1.2 relies on contributory > > behaviour. 25519 doesn't provide that unless you do some extra > > checking that we know many implementations don't do. > > > > I'd be OK with either requiring session hash, some checking of values, > > or both. Otherwise we create a situation where the shared secret can > > be forced by an attacker. > > The draft already has the checks. > > I also think I figured out a way to truly force contributory behaviour > without any checks: > > It is a bit nasty hack: Throw the exchange keys into the PMS, expanding > it from 32/56 bytes to 96/168 bytes. Why not hash the public values into the result of the key exchange? I don't want security to depend on omittable checks. > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --001a1144fe5205c4c5052826a977 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Dec 30, 2015 7:08 PM, "Ilari Liusvaara" <ilariliusvaara@welho.com> wrote:
>
> On Thu, Dec 31, 2015 at 09:55:10AM +1100, Martin Thomson wrote:
> > On 30 December 2015 at 22:16, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> > >> Would it make sense to have session hash as a requiremen= t in TLS
> > >> 1.2 when you want to use Curve25519?
> > >
> > > I don't think that is reasonable.
> >
> > I think that is entirely reasonable.=C2=A0 TLS 1.2 relies on cont= ributory
> > behaviour.=C2=A0 25519 doesn't provide that unless you do som= e extra
> > checking that we know many implementations don't do.
> >
> > I'd be OK with either requiring session hash, some checking o= f values,
> > or both.=C2=A0 Otherwise we create a situation where the shared s= ecret can
> > be forced by an attacker.
>
> The draft already has the checks.
>
> I also think I figured out a way to truly force contributory behaviour=
> without any checks:
>
> It is a bit nasty hack: Throw the exchange keys into the PMS, expandin= g
> it from 32/56 bytes to 96/168 bytes.

Why not hash the public values into the result of the key ex= change? I don't want security to depend on omittable checks.
>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--001a1144fe5205c4c5052826a977-- From nobody Wed Dec 30 16:30:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5131A013B for ; Wed, 30 Dec 2015 16:30:55 -0800 (PST) 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, HTML_MESSAGE=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 g9P5b-ROYALH for ; Wed, 30 Dec 2015 16:30:54 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD951A0130 for ; Wed, 30 Dec 2015 16:30:53 -0800 (PST) Received: by mail-yk0-x22f.google.com with SMTP id a85so91671788ykb.1 for ; Wed, 30 Dec 2015 16:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+mwzxQlBePiUnA+oNAeZ4OAqkHXaiFdw7Q6dnjQr8xo=; b=jHiVu+Xj14xhjSR+eKkCXERmQTYZDwD5TfnBvymNTG1YvAevbfA6uxsiHOrN6/OlPM sSswXHYNOnRsHDcUZOEtD+9acnP4q1cikhqX5ZSLJr6TRbrhBCADUsw+Ov46fAbVSLrN s0Q+a8FYG0C4Ufu3kGacVk+2IZrQvW4koGhbB2IhF2u/rWZIqnYdlsKM+1srJypgylGt 06tx7z6GAfrwW1yK2Q40bOtEOfmE7/PNvEHHUQitnDNk/icaAzmwOpBpXlvKKbARo2+6 kjM4CIKGJGBFgmI9UFZfdUxzlqtqiqqEa3jQCLQqxMz6Y+7Eu/11FwrlN1r+mnf4N7IQ iOGg== 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=+mwzxQlBePiUnA+oNAeZ4OAqkHXaiFdw7Q6dnjQr8xo=; b=ZwO8Gyrs1tzNZe94MooR5x8WuivPeX8OjLu826hBf38mMvWUZXjkHNFjAmc/yqVZy+ EZBpTg5Q3MkKmEs8w+Y5w+TtqYOMn5Ph7cAJoyJ3OO6CWVCdk3RdODJjDsivD8CFw2A/ EQ0Ge2mkkvQFZMVJfLcrqQxm1ouf4IMVAYyzEbWcx7PNe/UfNQRFDIOinHDowWArZMiE wjy46/gZVCzzA1yfmXEV5Ik2K1BXxvQLV13jCc0olV/bi4lEdjAAQty13QCwDbU1jC5O 7Pb/ETbBG+sEsDJk8kDQA6l0j+Lx9iFKLzRxNdUyHWg5/le8BlXhQ5HqxaXCqDdyhfXO qs2A== X-Gm-Message-State: ALoCoQkd3WBbHcMxM/w7ms6jhA5jSKIvqbNBIkMU+ImVsjqKP5ZiQr0kX41IK+5KwcQpP+ECQdK5XhIpR+1iowF+u7My5TgIlA== X-Received: by 10.129.73.133 with SMTP id w127mr56800376ywa.223.1451521853145; Wed, 30 Dec 2015 16:30:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Wed, 30 Dec 2015 16:30:13 -0800 (PST) In-Reply-To: References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> <20151230111631.GB23341@LK-Perkele-V2.elisa-laajakaista.fi> <20151231000803.GA23937@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Wed, 30 Dec 2015 19:30:13 -0500 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a114dcf6a70f532052826c4ff Archived-At: Cc: Karthikeyan Bhargavan , "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 00:30:55 -0000 --001a114dcf6a70f532052826c4ff Content-Type: text/plain; charset=UTF-8 On Wed, Dec 30, 2015 at 7:23 PM, Watson Ladd wrote: > > On Dec 30, 2015 7:08 PM, "Ilari Liusvaara" > wrote: > > > > On Thu, Dec 31, 2015 at 09:55:10AM +1100, Martin Thomson wrote: > > > On 30 December 2015 at 22:16, Ilari Liusvaara < > ilariliusvaara@welho.com> wrote: > > > >> Would it make sense to have session hash as a requirement in TLS > > > >> 1.2 when you want to use Curve25519? > > > > > > > > I don't think that is reasonable. > > > > > > I think that is entirely reasonable. TLS 1.2 relies on contributory > > > behaviour. 25519 doesn't provide that unless you do some extra > > > checking that we know many implementations don't do. > > > > > > I'd be OK with either requiring session hash, some checking of values, > > > or both. Otherwise we create a situation where the shared secret can > > > be forced by an attacker. > > > > The draft already has the checks. > > > > I also think I figured out a way to truly force contributory behaviour > > without any checks: > > > > It is a bit nasty hack: Throw the exchange keys into the PMS, expanding > > it from 32/56 bytes to 96/168 bytes. > > Why not hash the public values into the result of the key exchange? I > don't want security to depend on omittable checks. > Note that session-hash does this, so it seems best to use session-hash if you want to adopt this strategy. -Ekr > > > > > > -Ilari > > > > _______________________________________________ > > 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 > > --001a114dcf6a70f532052826c4ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 30, 2015 at 7:23 PM, Watson Ladd <watsonbladd@gmail.co= m> wrote:
=


On Dec 30, 2015 7:08 PM, "Ilari Liusvaara" <ilariliusvaara@welho.com>= ; wrote:
>
> On Thu, Dec 31, 2015 at 09:55:10AM +1100, Martin Thomson wrote:
> > On 30 December 2015 at 22:16, Ilari Liusvaara <ilariliusvaara@welho.com= > wrote:
> > >> Would it make sense to have session hash as a requiremen= t in TLS
> > >> 1.2 when you want to use Curve25519?
> > >
> > > I don't think that is reasonable.
> >
> > I think that is entirely reasonable.=C2=A0 TLS 1.2 relies on cont= ributory
> > behaviour.=C2=A0 25519 doesn't provide that unless you do som= e extra
> > checking that we know many implementations don't do.
> >
> > I'd be OK with either requiring session hash, some checking o= f values,
> > or both.=C2=A0 Otherwise we create a situation where the shared s= ecret can
> > be forced by an attacker.
>
> The draft already has the checks.
>
> I also think I figured out a way to truly force contributory behaviour=
> without any checks:
>
> It is a bit nasty hack: Throw the exchange keys into the PMS, expandin= g
> it from 32/56 bytes to 96/168 bytes.

Why not hash the public values into the result of the= key exchange? I don't want security to depend on omittable checks.

=
Note that session-hash does this, so it seems best to use= session-hash if you want
to adopt this strategy.
<= br>
-Ekr


>
>
> -Ilari
>
> _______________________________________________
> 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


--001a114dcf6a70f532052826c4ff-- From nobody Wed Dec 30 16:32:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5AC1A013B for ; Wed, 30 Dec 2015 16:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 FnsjttSiUt-y for ; Wed, 30 Dec 2015 16:32:22 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id AD1331A012F for ; Wed, 30 Dec 2015 16:32:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 946AE1AA; Thu, 31 Dec 2015 02:32:21 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id iNNetRscDgZ3; Thu, 31 Dec 2015 02:32:21 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 4951E230D; Thu, 31 Dec 2015 02:32:21 +0200 (EET) Date: Thu, 31 Dec 2015 02:32:20 +0200 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20151231003220.GB23937@LK-Perkele-V2.elisa-laajakaista.fi> References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> <20151230111631.GB23341@LK-Perkele-V2.elisa-laajakaista.fi> <20151231000803.GA23937@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: Karthikeyan Bhargavan , "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 00:32:24 -0000 On Wed, Dec 30, 2015 at 07:23:12PM -0500, Watson Ladd wrote: > On Dec 30, 2015 7:08 PM, "Ilari Liusvaara" wrote: > > > > I also think I figured out a way to truly force contributory behaviour > > without any checks: > > > > It is a bit nasty hack: Throw the exchange keys into the PMS, expanding > > it from 32/56 bytes to 96/168 bytes. > > Why not hash the public values into the result of the key exchange? I don't > want security to depend on omittable checks. What values you think are realistically available at that point, other than the exchange public keys? -Ilari From nobody Wed Dec 30 16:47:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D36A1A0173 for ; Wed, 30 Dec 2015 16:47:22 -0800 (PST) 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, 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 wvpgkOdy-PP5 for ; Wed, 30 Dec 2015 16:47:21 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5834F1A016C for ; Wed, 30 Dec 2015 16:47:21 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id y66so209955188oig.0 for ; Wed, 30 Dec 2015 16:47:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/je4jzKinUP6hnLcsbx+zyM3PfmdJg5YIjNEwAmVQ7M=; b=OyaPt0Z/7V2EVmB+PLysVu83mTVPUwGZuzNIRY8GPEXr0wtbr5iSKT8fsZ2kuHjuMI NbA3/kwpVs72XC7tjFHacJq3yTtjNVyLoqCm18j069nnwxiA8kWezh3cWd9zr2wayKhO F7bDnNzXYRuMJQInLg6IAvNMp1WSuxlEm4hkDei/DLuRst9JCEgyOHcolVLBaiR8NkB8 hEk3uwq93QQde3CSmERp5CjywZLrIh7gSdr8AcK0XL3XSjbx5+AN3OevdpjjtLRDCQix BU+xSZx3+k5+swWJ05NZ+mgYZA9BMWC4Y5iCbDmVO9eB4MjjZoUr3c9nTdKnSfbxmmYe a2aw== 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=/je4jzKinUP6hnLcsbx+zyM3PfmdJg5YIjNEwAmVQ7M=; b=GPrBl9flQOD6d/HBeigcR+RK8+alMBKVnjAZekY/oPRijf2lGVJXZfj3CwuJvBLH2O sLE6RbrTsaQRcCnxfAIQyJuyyc95WRdQE9BiTG3XDoqBIpvFjkfRz15iSE/vSdh2AEIR vb7mTKSsXQ2wCCOHmLUCIDn2onlMTxHpX50eFPYpjbhl5CVq4D6H+Qck3bkuao5YBLi5 ov/pfJzLlPy2BrZ2MUkyFOH159i8lLwhb+2X8nLwA+UFszI7qfM9N/icAigcooZ3cWo3 NEpzx8ovRIqlRyykudPnzh5xJHuUHKy8LBy2F4VcD39Fd6LDgPnN4gI3dW0VY8qUapln vQHQ== X-Gm-Message-State: ALoCoQnfdoeU8TkGNeL9hhd4sqEPTSrM9uUKak+sf2uWq0DzX6iNSksmGe564g6THQjDUYR3r1E6dM7gkYXFxK4Wj6Ultgo4eA== MIME-Version: 1.0 X-Received: by 10.202.189.7 with SMTP id n7mr42626884oif.55.1451522840701; Wed, 30 Dec 2015 16:47:20 -0800 (PST) Received: by 10.76.62.8 with HTTP; Wed, 30 Dec 2015 16:47:20 -0800 (PST) In-Reply-To: References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> <20151230111631.GB23341@LK-Perkele-V2.elisa-laajakaista.fi> <20151231000803.GA23937@LK-Perkele-V2.elisa-laajakaista.fi> Date: Wed, 30 Dec 2015 14:47:20 -1000 Message-ID: From: Brian Smith To: Watson Ladd Content-Type: multipart/alternative; boundary=001a113d70324df040052826ff96 Archived-At: Cc: Karthikeyan Bhargavan , "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 00:47:22 -0000 --001a113d70324df040052826ff96 Content-Type: text/plain; charset=UTF-8 Watson Ladd wrote: > Why not hash the public values into the result of the key exchange? I > don't want security to depend on omittable checks. > One would need an omittable check in the code to decide whether to do that extra hashing, so that wouldn't solve the (non-)problem of "omittable checks". Similarly, one would need an omittable check to decide whether to require the session hash extension, so it wouldn't solve the (non-)problem of "omittable checks". Actually, because the check for non-zero result can/should/is in the X25519/X448 functions themselves, the check for non-zero result is the least likely of all these possible solutions to be omitted. And, it is also the easiest to test. Cheers, Brian -- https://briansmith.org/ --001a113d70324df040052826ff96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wats= on Ladd <watsonbladd@gmail.com> wrote:

Why not hash the public values into the = result of the key exchange? I don't want security to depend on omittabl= e checks.


One would need an = omittable check in the code to decide whether to do that extra hashing, so = that wouldn't solve the (non-)problem of "omittable checks".<= /div>

Similarly, one would need an omittable check to de= cide whether to require the session hash extension, so it wouldn't solv= e the (non-)problem of "omittable checks".

Actually, because the check for non-zero result can/should/is in the X25= 519/X448 functions themselves, the check for non-zero result is the least l= ikely of all these possible solutions to be omitted. And, it is also the ea= siest to test.

Cheers,
Brian
= --
--001a113d70324df040052826ff96-- From nobody Wed Dec 30 18:16:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011A61A037B for ; Wed, 30 Dec 2015 18:16:15 -0800 (PST) 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 g0VJFxGgtV25 for ; Wed, 30 Dec 2015 18:16:13 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669CD1A037A for ; Wed, 30 Dec 2015 18:16:13 -0800 (PST) Received: by mail-yk0-x234.google.com with SMTP id v14so77134451ykd.3 for ; Wed, 30 Dec 2015 18:16:13 -0800 (PST) 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=cZoDM+z0kS/vrK8L62VdSWu/00XkxGCh3v8xowaqExU=; b=QuGN9kPOd7AwbKtX7LY0WWuFKMsQhqFzsvYul4nXX4DwP8P44t/sPcxMYlESjPl6vs 5hrlNbvzzgIJnE9NAFOSZUj+NZDBbOy48QZfO3rHowJfsN+t3mFJldp5WkvfsDC8ctnQ ANsNAQGJXabR/P+zvrsy/tStA2admE3sQWjBS5aOq53PVyXh8g885zKG2XhNciSMUQev tMH6Ma1AHu0psQpnMLUfOr8pApyTHaXgftLaqNlbn+NESrOPKyQz5dccI/YavuVmpu9e 290dqOY1gOK5p+CjqYOCcFOxSyyR4bgJ5Y7U04eTRuuUkVIbSD2jL+J6GCW+5bd/sBPb A1Kg== MIME-Version: 1.0 X-Received: by 10.13.226.137 with SMTP id l131mr57555666ywe.239.1451528172658; Wed, 30 Dec 2015 18:16:12 -0800 (PST) Received: by 10.13.216.150 with HTTP; Wed, 30 Dec 2015 18:16:12 -0800 (PST) In-Reply-To: References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> <20151230111631.GB23341@LK-Perkele-V2.elisa-laajakaista.fi> <20151231000803.GA23937@LK-Perkele-V2.elisa-laajakaista.fi> Date: Wed, 30 Dec 2015 21:16:12 -0500 Message-ID: From: Watson Ladd To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Karthikeyan Bhargavan , "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 02:16:15 -0000 On Wed, Dec 30, 2015 at 7:47 PM, Brian Smith wrote: > Watson Ladd wrote: >> >> Why not hash the public values into the result of the key exchange? I >> don't want security to depend on omittable checks. > > > One would need an omittable check in the code to decide whether to do that > extra hashing, so that wouldn't solve the (non-)problem of "omittable > checks". > > Similarly, one would need an omittable check to decide whether to require > the session hash extension, so it wouldn't solve the (non-)problem of > "omittable checks". > > Actually, because the check for non-zero result can/should/is in the > X25519/X448 functions themselves, the check for non-zero result is the least > likely of all these possible solutions to be omitted. And, it is also the > easiest to test. Failure to compute H(A, B, X25591(a, B)) would result in an interoperability failure with any other implementation of this ciphersuite. By contrast a zero check will not be exercised by basic interoperability testing, nor would mandatory use of session hash. All currently existing implementations of the X25519 function do not perform zero checks. Ones that do have to return a value, which can easily be ignored. Short of calling abort there is no way for implementors of cryptographic functions to ensure that callers pay attention to return values. > > Cheers, > Brian > -- > https://briansmith.org/ > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Dec 30 19:30:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA431A6F07 for ; Wed, 30 Dec 2015 19:30:10 -0800 (PST) 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 QqYKG1GVyYzY for ; Wed, 30 Dec 2015 19:30:09 -0800 (PST) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6761A6F01 for ; Wed, 30 Dec 2015 19:30:08 -0800 (PST) Received: by mail-qg0-x22b.google.com with SMTP id 6so117423615qgy.1 for ; Wed, 30 Dec 2015 19:30:08 -0800 (PST) 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=Z+TS71f3hhFIIdeLVKsOVd80CKOqtv3b80iwkwYpTqg=; b=lDGAzk4MVSMVHNFwI3KizQ85vHL41CBFK8qMAbe4r6cJSN1HBQ2gpOph9gW6C6DI2e Gkghr+ghAtBe3UTQOz19cIjFeqfJHK5zwxqFTytT5xYPIbX9Lp472s7c/WauB4PKMq9Y bIbeemPAlmOKkZbtNL3+MI0SdbKJuqW7gIGRZUwsQs4vJaXVbcIeMNdtRpGBoKz0NTE8 R0CRnIRn1HSorkFZY+SJPOQblmmHTRWh/osn0HrXQIHtm91qtE16Js5Dm7XK8Bj8CxkU 6EfY61U7jwRZx+UP1OJv0e+72jBt7XwWawNUf6JMLu9ryb9HXAuLD0G44je6YmTJBAL2 GUvg== MIME-Version: 1.0 X-Received: by 10.140.232.78 with SMTP id d75mr77755428qhc.27.1451532608158; Wed, 30 Dec 2015 19:30:08 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.93.12 with HTTP; Wed, 30 Dec 2015 19:30:08 -0800 (PST) In-Reply-To: References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> Date: Wed, 30 Dec 2015 19:30:08 -0800 X-Google-Sender-Auth: _IoEi4--Fit6jMAdgEBWhvPIHDE Message-ID: From: Adam Langley To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Karthikeyan Bhargavan , "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 03:30:10 -0000 On Wed, Dec 30, 2015 at 4:03 PM, Brian Smith wrote: > I think it is a good idea to implement the session hash extension, in > general. However, I think it is a bad idea to prescribe it as the solution > for this particular problem because: > > 1. draft-irtf-cfrg-curves-11, in sections 6.1 and section 6.2 already > require the check for a non-zero result, and that check is sufficient. As discussed on the CFRG list, the plan is that the final curves RFC will say that the zero check is a MAY. (See https://www.ietf.org/mail-archive/web/cfrg/current/msg07611.html) I don't mind if the integration of curve25519 in TLS requires a zero-check or not, but what property are people hoping to gain? If one wants to avoid triple-handshake like issues then session-hash is the answer. A client can use an RSA key exchange to control the PMS completely, of course, and, with finite-field DH, a value of zero or p-1 will usually allow the same. Cheers AGL From nobody Wed Dec 30 19:40:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DB11A6F2F for ; Wed, 30 Dec 2015 19:40:55 -0800 (PST) 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, 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 I4_ZNcQJvWB1 for ; Wed, 30 Dec 2015 19:40:53 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85EA91A6F29 for ; Wed, 30 Dec 2015 19:40:53 -0800 (PST) Received: by mail-ob0-x231.google.com with SMTP id 18so282975729obc.2 for ; Wed, 30 Dec 2015 19:40:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CqLtdKRTdmmKKB14OXMMAu2EGu6rlYU0cn1E4P+f4o0=; b=MmckVbysaSfboYjzfQvR78qWjgRUdi3iV8UkS+yLArzTH8MZiSIhi5vc2OyfSvB54Z 2oxk0iF5DZw7UATw/gl58w0gyAasRq8EqO1qVCvczk8Fsg9Eu5NqEzsX3D+Lqh53a/M8 lExS69bal4yrxeN/ZCIgpRfVxvNZvznMrEjhZt664dbGC3o0RwhCTd5MAxy1KQuEN1fJ Yejcq38zX29B/RNirnP7NVKw/sw3nM/5m5ykCHWpGQW/3ELdx4QtxJX4bNHvp+j8nfrp m1NuL6jjWxqHJzqI3UGxR+iXaqsXcwi2pkOPN9KzRnt1UsJPF4/3vUDpQxGpPPkRCuZA ItOA== 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=CqLtdKRTdmmKKB14OXMMAu2EGu6rlYU0cn1E4P+f4o0=; b=IfqlkEbUXAeWufKTxAI/Vsi5I3pBWim1bGaS4SX8WxtKZTMST+9kSJpl0JVQ2tzpf6 aei5KQNRwcj9y3NjhSijAqqKUkL9+ZgQ0ghdsuYb2AR4kz8llt59bheLFmyFAV+BVZDR jkussNDrmuPok/cVAUNy2LKNE01Fj4MKICG/mVFKQoyXaoneeRaBV1oZ34noSyu89/oi CTwvzw8krux1jcWhvuEc1jf9nphK7cXOE+tP9A2Sjas4oZmfdF8tzNSU2ZvatmRjdy/B r/81NtgqU2MWuZYygLU84EJq9Haw6hp03gcMn27RIp7M6K2KnSJ1Hq8gLU2Ic7GKu4En QDyA== X-Gm-Message-State: ALoCoQkv2LDSU3isI3yUH6Bg6eoGtfYcgp1g/FL25cbQ6MJNN72VerkdpNQfaG36fc94GL0nzTG7tCrCQzShVv7QCYzAmV9icw== MIME-Version: 1.0 X-Received: by 10.60.134.202 with SMTP id pm10mr14467090oeb.50.1451533252894; Wed, 30 Dec 2015 19:40:52 -0800 (PST) Received: by 10.76.62.8 with HTTP; Wed, 30 Dec 2015 19:40:52 -0800 (PST) In-Reply-To: References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> Date: Wed, 30 Dec 2015 17:40:52 -1000 Message-ID: From: Brian Smith To: Adam Langley Content-Type: multipart/alternative; boundary=047d7b417a63eb3c960528296b50 Archived-At: Cc: Karthikeyan Bhargavan , "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 03:40:55 -0000 --047d7b417a63eb3c960528296b50 Content-Type: text/plain; charset=UTF-8 Adam Langley wrote: > On Wed, Dec 30, 2015 at 4:03 PM, Brian Smith wrote: > > > I think it is a good idea to implement the session hash extension, in > > general. However, I think it is a bad idea to prescribe it as the > solution > > for this particular problem because: > > > > 1. draft-irtf-cfrg-curves-11, in sections 6.1 and section 6.2 already > > require the check for a non-zero result, and that check is sufficient. > > As discussed on the CFRG list, the plan is that the final curves RFC > will say that the zero check is a MAY. (See > https://www.ietf.org/mail-archive/web/cfrg/current/msg07611.html) > When you say "the plan," whose plan are you referring to? If you read that whole thread, there was a lot of well-founded opposition to that plan. And, that plan was never carried out. That is plain to see, as there was never a draft submitted with such a change. So, I assumed that "the plan" was dropped. This isn't a minor editorial change, so it wouldn't be appropriate (IMO) to have the final spec changed in this respect without having had that change reflected in any draft that people have actually been reviewing. > I don't mind if the integration of curve25519 in TLS requires a > zero-check or not, but what property are people hoping to gain? If one > wants to avoid triple-handshake like issues then session-hash is the > answer. Session Hash is *an* answer, but, for the reasons I already gave in this thread, it isn't the best answer for this. A client can use an RSA key exchange to control the PMS > completely, of course, and, with finite-field DH, a value of zero or > p-1 will usually allow the same. Not if the implementation doesn't implement RSA or finite-field DH. Cheers, Brian -- https://briansmith.org/ --047d7b417a63eb3c960528296b50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adam= Langley <agl@imperialviolet.org> wrote:
On Wed, Dec 30, 2015 at 4:03 PM, Brian= Smith <brian@briansmith.org= > wrote:

> I think it is a good idea to implement the session hash extension, in<= br> > general. However, I think it is a bad idea to prescribe it as the solu= tion
> for this particular problem because:
>
> 1. draft-irtf-cfrg-curves-11, in sections 6.1 and section 6.2 already<= br> > require the check for a non-zero result, and that check is sufficient.=

As discussed on the CFRG list, the plan is that the final curves RFC=
will say that the zero check is a MAY. (See
https://www.ietf.org/mail-archive/we= b/cfrg/current/msg07611.html)

When = you say "the plan," whose plan are you referring to? If you read = that whole thread, there was a lot of well-founded opposition to that plan.= And, that plan was never carried out. That is plain to see, as there was n= ever a draft submitted with such a change. So, I assumed that "the pla= n" was dropped. This isn't a minor editorial change, so it wouldn&= #39;t be appropriate (IMO) to have the final spec changed in this respect w= ithout having had that change reflected in any draft that people have actua= lly been reviewing.
=C2=A0
I = don't mind if the integration of curve25519 in TLS requires a
zero-check or not, but what property are people hoping to gain? If one
wants to avoid triple-handshake like issues then session-hash is the
answer.

Session Hash is *an* answer, but, f= or the reasons I already gave in this thread, it isn't the best answer = for this.=C2=A0

A client= can use an RSA key exchange to control the PMS
completely, of course, and, with finite-field DH, a value of zero or
p-1 will usually allow the same.

Not if the= implementation doesn't implement RSA or finite-field DH.
Cheers,
Brian
--
--047d7b417a63eb3c960528296b50-- From nobody Wed Dec 30 22:23:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C8E1A802D for ; Wed, 30 Dec 2015 22:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 h_R_cP2AlJqC for ; Wed, 30 Dec 2015 22:23:03 -0800 (PST) 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 3526F1A03FF for ; Wed, 30 Dec 2015 22:23:03 -0800 (PST) To: tls@ietf.org References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> From: Alyssa Rowan X-Enigmail-Draft-Status: N1110 Message-ID: <5684C9CC.2080703@akr.io> Date: Thu, 31 Dec 2015 06:23:08 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 06:23:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2015-12-31 03:30, Adam Langley wrote: > I don't mind if the integration of curve25519 in TLS requires a > zero-check or not, but what property are people hoping to gain? If > one wants to avoid triple-handshake like issues then session-hash > is the answer. (I have a terrible cold, so apologies if I am less than coherent!) I think I prefer this, of the available options. Specify that: • Both client and server MUST abort if X25519 and/or X448 are offered/chosen but session_hash is not; • Explain why in Security Considerations; • Test as part of interop/unit tests? Zero checks are more likely to be omitted in practice because all the implementations out there already do that and don't return a value. And it's not something the peer would notice in normal operation. Watson's approach might work too, but of the available options I think ensuring the transcript is hashed is the most robust with respect to any future attacks. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWhMnAAAoJEOyEjtkWi2t6wZsQAJk767t5ZE28uDYsSCT1fS9u z6szG2xGnq6jc4T40AZEWeabs9j0n15MZHvFkxQwmtF00dUspIrcRzpct8hXkx0K q83rotDKGIiCU9K9a6E4Xas/cxxQ8LDTtB937PsyOIpzPOe/fXHu+KTIgtrLL7Cb OefYyGf7ymRVm0UP9IrIkK99enu0HPuMjqcDdKfW9JVAvb+jgfTyO+qDipYtH8s0 jo3HhCsMiCJlxFaI32viREW/Jcwu4cyttjCvgOPCQUmJ3TQdAC1ucWXpNHgRp07y RY3+TJfNx9tmmgOoXvGox67hoKKvFaSO8ckqhXrG/V46xLP2FNDEEsaGd0cuKeEb 7T+/0ae9/mzQm3PYhpufU+FiroTDUuYKvjTHfzEY7xPjjpeQT/OdqyrEseJqFfCC sCKQQPx40vg1dwU6pJ7KyCEJ14RVY5rXmhvkKjGnfI5tziykKibMnqF1MbPh/BK/ L35fQyeJVb6rAaL8iPJx/ilvdJDESAgWic/UooywWkU8HrH6FAXiIV6i1BmkscXn e3yQB55SVYHv+yPfcNJAyZDXYVln6EoFwVU3rjYxcnAib2z52m2HOyh7NjrBpvVx 8CuIxU+FytE8BUrkayciOS2AFvGUIsf0c/eogDX9A10U6pOoFCRigLRYKFgRbJ3l M19UbePdsDBYgnd5sEel =CRt3 -----END PGP SIGNATURE----- From nobody Wed Dec 30 22:51:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BA71A86FB for ; Wed, 30 Dec 2015 22:51:04 -0800 (PST) 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 x9gOcwEcmGQf for ; Wed, 30 Dec 2015 22:51:03 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D466E1A86FA for ; Wed, 30 Dec 2015 22:51:02 -0800 (PST) Received: by mail-ig0-x22f.google.com with SMTP id mv3so156552699igc.0 for ; Wed, 30 Dec 2015 22:51:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=CH8srKuTjF2SxO/wAB30v2m+8U9oDb89BmbM2BOv/y4=; b=h6hKe+4vJWOhRjC6JiInVMRlhYqgSioSIjk+JdZ/E5yh749vL9U7FbXARaeJ7o0v7y 9QUr5znwsexAtzDw3knx5cCfdPv1baGIOvkD+EI9/hU7yeCQK18+rIlwYmoTVCz/HVBv no+bHWX0nBSjOuoprs/Xsr8p2Jurogd3TMSmHnWJaIlhXb6TVqNn7fnKoKtyXJCm9Vno Lpr9lZWhFfYqEufoO9PPofR7ZnxhTWrM4DOJCMwgbQOf7R80Gb/UCVYXhJVbU9nEajV9 Upqu+smKPFuPnmwW0cykGpTd3DKJ2eCQC+Q9IR6Gz0pnavXf3+5Teuys1Ekps4ITtqcE ceEQ== MIME-Version: 1.0 X-Received: by 10.50.30.134 with SMTP id s6mr61730162igh.36.1451544662226; Wed, 30 Dec 2015 22:51:02 -0800 (PST) Received: by 10.36.31.66 with HTTP; Wed, 30 Dec 2015 22:51:02 -0800 (PST) In-Reply-To: <5684C9CC.2080703@akr.io> References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> <5684C9CC.2080703@akr.io> Date: Thu, 31 Dec 2015 01:51:02 -0500 Message-ID: From: Jeffrey Walton To: Alyssa Rowan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.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, 31 Dec 2015 06:51:04 -0000 On Thu, Dec 31, 2015 at 1:23 AM, Alyssa Rowan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 2015-12-31 03:30, Adam Langley wrote: > >> I don't mind if the integration of curve25519 in TLS requires a >> zero-check or not, but what property are people hoping to gain? If >> one wants to avoid triple-handshake like issues then session-hash >> is the answer. > > (I have a terrible cold, so apologies if I am less than coherent!) > > I think I prefer this, of the available options. Specify that: > > =E2=80=A2 Both client and server MUST abort if X25519 and/or X448 are > offered/chosen but session_hash is not; > =E2=80=A2 Explain why in Security Considerations; > =E2=80=A2 Test as part of interop/unit tests? I think the above sets up a situation where the safer curves are tied to 0-RTT and friends. I'm pretty sure any configuration under my purview will *not* have 0-RTT enabled. My servers will *not* be consuming data before it has been authenticated. I can only say I'm "pretty sure". I won't know for certain until I actually step the code under a debugger and see what is being consumed in the negative cases. My apologies if I am parsing it incorrectly or going against the grain. Jeff From nobody Wed Dec 30 22:54:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518F91A8704 for ; Wed, 30 Dec 2015 22:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 4mOxAHUrR8PQ for ; Wed, 30 Dec 2015 22:54:54 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 16D161A86FC for ; Wed, 30 Dec 2015 22:54:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 4F6F414B; Thu, 31 Dec 2015 08:54:53 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id BJEkeZHZ34TS; Thu, 31 Dec 2015 08:54:53 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id F15422310; Thu, 31 Dec 2015 08:54:52 +0200 (EET) Date: Thu, 31 Dec 2015 08:54:51 +0200 From: Ilari Liusvaara To: Alyssa Rowan Message-ID: <20151231065451.GA24161@LK-Perkele-V2.elisa-laajakaista.fi> References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> <5684C9CC.2080703@akr.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5684C9CC.2080703@akr.io> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 06:54:56 -0000 On Thu, Dec 31, 2015 at 06:23:08AM +0000, Alyssa Rowan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 2015-12-31 03:30, Adam Langley wrote: > > > I don't mind if the integration of curve25519 in TLS requires a > > zero-check or not, but what property are people hoping to gain? If > > one wants to avoid triple-handshake like issues then session-hash > > is the answer. > > (I have a terrible cold, so apologies if I am less than coherent!) > > I think I prefer this, of the available options. Specify that: > > • Both client and server MUST abort if X25519 and/or X448 are > offered/chosen but session_hash is not; > • Explain why in Security Considerations; > • Test as part of interop/unit tests? > > Zero checks are more likely to be omitted in practice because all the > implementations out there already do that and don't return a value. > And it's not something the peer would notice in normal operation. The problems with this: The THS check is a check. Zero checks can already be unit-tested/interop-tested just as well. If you do anything that is vulernable to THS, you better take severe countermeasures at application layer (check for EMS, mix in certs, refuse resumption, dump and hash transcripts, etc...) already. As for reliability of using ECDHE... I wouldn't rely that random implementation of ECDHE is safe against THS, even with cofactor 1 Weierstrass curves. And unit-testing/interop-testing some of the issues involved is just plain nasty. > Watson's approach might work too, but of the available options I think > ensuring the transcript is hashed is the most robust with respect to > any future attacks. Actually, I proposed something very similar, but without a hash (HMAC would likely hash that thing anyway[1]). That one does not have any checks. [1] Specifically, unless X25519 is used with ciphersuite with SHA-384 as PRF-hash. -Ilari From nobody Thu Dec 31 07:55:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924CA1A1B8B for ; Thu, 31 Dec 2015 07:55:15 -0800 (PST) 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, HTML_MESSAGE=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 MQxQ1csQJJO9 for ; Thu, 31 Dec 2015 07:55:13 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E911A1B89 for ; Thu, 31 Dec 2015 07:55:13 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id v14so89225957ykd.3 for ; Thu, 31 Dec 2015 07:55:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lRK4ieNOLQgxsRlb7x2V3Z6GtpySWAKKeZqzedYQMbU=; b=oSWV8kxliMrjni3Ct5DPjHbrgWXaxikkZ0MIsLkloduDbxZUHoAyWAA4/41MVlYwTl 07bL4/MeRnTCASd6bi7WO7fitg+taX+/MxXbh+AG18mCHzJzdmvmYN1GOXP+voXQD4MH WNmRl7nyq+Xy/FwXC2NukupFz1gxbnNJHOo60azYY2+tQtLzAOvYgolhtuZVC2uGFvKg /ZCXy7v444pAWBAKW3iXNUjcqA4dLFvQigENnkYS3n5FXyeey9HHZADa8Hv9nIEbHEMi lclUHZuOGTQhMV8V8QrF4W7MpvrDAHf2IeiDfYtygo1hTUhTT6yOOGpSWE13Qyikxnb6 Yh7A== 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=lRK4ieNOLQgxsRlb7x2V3Z6GtpySWAKKeZqzedYQMbU=; b=joxY9DjNj8OeleZUdzF0129Trwk6sF+bRKKYdmj7Z7XsudP5Zb0RPljMvLkWvS9voU LKVmVzyiJOGhUZ/8ZZtNGrgDadSA0AXS1sFbUBL4Ek3eC+rnahtUA7NvNfdQQEBmZMM/ RuISJkHUJLlvR0lt275+FKt3UhwL/iaDCFSSPp6wD5n0GKbsw45GkLZr1cuQOF3lrK8P BIQMqq47odTVxqEMbyQIZvlKrv/txM5b238SVy8mdH2h7mBSrHSeTn7LqRd1YpWtBoje Z12v4MkNo0Lle6rYugm+B/NiCr/XoEQ/ILUgnO2iiwg/tJTt4x7CuLA+1OmOW3nzPP8D vBpg== X-Gm-Message-State: ALoCoQkmmG7F2XiPrD6zSPteVWFO6jjyOKX+573a9URbe/Zv8swd/engOyKyxw88WqP7O5eLM43AZtvpq9DAe4zwMP6ag29DsQ== X-Received: by 10.129.46.208 with SMTP id u199mr51771462ywu.129.1451577312754; Thu, 31 Dec 2015 07:55:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Thu, 31 Dec 2015 07:54:33 -0800 (PST) In-Reply-To: <20151231065451.GA24161@LK-Perkele-V2.elisa-laajakaista.fi> References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> <5684C9CC.2080703@akr.io> <20151231065451.GA24161@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Thu, 31 Dec 2015 07:54:33 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11408592178ba3052833ae4c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 15:55:15 -0000 --001a11408592178ba3052833ae4c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm finding myself a bit unclear on the scenario people are concerned about= . It seems like there are two potential cases: 1. You have an implementation which already does some of the algorithms we know are susceptible to THS-type attacks. 2. You have an implementation which only does the CFRG curves. In the first case, if you are in a scenario where THS is relevant, then you should be insisting on session hash for the existing algorithms and so it's simplest to just always insist on session hash. And if you're failing to do so, then it's not clear to me how having the CFRG curves be safe here helps (it might be true, but I haven't convinced myself of it.) In a previous thread, Brian suggested an implementation that was just CFRG curves, so perhaps that's the scenario of interest? But in that case you can just *only* implement session hash. Specifically, you insist on negotiating the extension but only implement the session hash key derivation, rather than the normal key derivation, so there's not really a check to omit [0]. Am I missing something? -Ekr [0] This is effectively how 1.3 behaves by just always requiring session hash. On Wed, Dec 30, 2015 at 10:54 PM, Ilari Liusvaara wrote: > On Thu, Dec 31, 2015 at 06:23:08AM +0000, Alyssa Rowan wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > On 2015-12-31 03:30, Adam Langley wrote: > > > > > I don't mind if the integration of curve25519 in TLS requires a > > > zero-check or not, but what property are people hoping to gain? If > > > one wants to avoid triple-handshake like issues then session-hash > > > is the answer. > > > > (I have a terrible cold, so apologies if I am less than coherent!) > > > > I think I prefer this, of the available options. Specify that: > > > > =E2=80=A2 Both client and server MUST abort if X25519 and/or X448 are > > offered/chosen but session_hash is not; > > =E2=80=A2 Explain why in Security Considerations; > > =E2=80=A2 Test as part of interop/unit tests? > > > > Zero checks are more likely to be omitted in practice because all the > > implementations out there already do that and don't return a value. > > And it's not something the peer would notice in normal operation. > > The problems with this: > > The THS check is a check. > > Zero checks can already be unit-tested/interop-tested just as well. > > If you do anything that is vulernable to THS, you better take severe > countermeasures at application layer (check for EMS, mix in certs, > refuse resumption, dump and hash transcripts, etc...) already. > > As for reliability of using ECDHE... I wouldn't rely that random > implementation of ECDHE is safe against THS, even with cofactor 1 > Weierstrass curves. And unit-testing/interop-testing some of the > issues involved is just plain nasty. > > > Watson's approach might work too, but of the available options I think > > ensuring the transcript is hashed is the most robust with respect to > > any future attacks. > > Actually, I proposed something very similar, but without a hash (HMAC > would likely hash that thing anyway[1]). That one does not have any > checks. > > > > [1] Specifically, unless X25519 is used with ciphersuite with SHA-384 > as PRF-hash. > > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11408592178ba3052833ae4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm finding myself a bit unclear on the scenario peopl= e are concerned about.

It seems like there are two poten= tial cases:

1. You have an implementation which al= ready does some of the algorithms
we know are susceptible to THS-= type attacks.
2. You have an implementation which only does the C= FRG curves.

In the first case, if you are in a sce= nario where THS is relevant, then you
should be insisting on sess= ion hash for the existing algorithms and so it's
simplest to = just always insist on session hash. And if you're failing to
= do so, then it's not clear to me how having the CFRG curves be safe
here helps (it might be true, but I haven't convinced myself of = it.)

In a previous thread, Brian suggested an impl= ementation that was just
CFRG curves, so perhaps that's the s= cenario of interest? But in that case
you can just *only* impleme= nt session hash. Specifically, you insist on
negotiating the exte= nsion but only implement the session hash key derivation,
rather = than the normal key derivation, so there's not really a check to
<= div>omit [0].

Am I missing something?
-Ekr

[0] This is effectively how 1.3 = behaves by just always requiring session hash.




On Wed, Dec 30, 2015 at 10:= 54 PM, Ilari Liusvaara <ilariliusvaara@welho.com> wro= te:
On Thu, Dec 31, 2015= at 06:23:08AM +0000, Alyssa Rowan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 2015-12-31 03:30, Adam Langley wrote:
>
> > I don't mind if the integration of curve25519 in TLS requires= a
> > zero-check or not, but what property are people hoping to gain? I= f
> > one wants to avoid triple-handshake like issues then session-hash=
> > is the answer.
>
> (I have a terrible cold, so apologies if I am less than coherent!)
>
> I think I prefer this, of the available options. Specify that:
>
> =E2=80=A2 Both client and server MUST abort if X25519 and/or X448 are<= br> >=C2=A0 =C2=A0offered/chosen but session_hash is not;
> =E2=80=A2 Explain why in Security Considerations;
> =E2=80=A2 Test as part of interop/unit tests?
>
> Zero checks are more likely to be omitted in practice because all the<= br> > implementations out there already do that and don't return a value= .
> And it's not something the peer would notice in normal operation.<= br>
The problems with this:

The THS check is a check.

Zero checks can already be unit-tested/interop-tested just as well.

If you do anything that is vulernable to THS, you better take severe
countermeasures at application layer (check for EMS, mix in certs,
refuse resumption, dump and hash transcripts, etc...) already.

As for reliability of using ECDHE... I wouldn't rely that random
implementation of ECDHE is safe against THS, even with cofactor 1
Weierstrass curves. And unit-testing/interop-testing some of the
issues involved is just plain nasty.

> Watson's approach might work too, but of the available options I t= hink
> ensuring the transcript is hashed is the most robust with respect to > any future attacks.

Actually, I proposed something very similar, but without a hash (HMA= C
would likely hash that thing anyway[1]). That one does not have any
checks.



[1] Specifically, unless X25519 is used with ciphersuite with SHA-384
as PRF-hash.




-Ilari

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

--001a11408592178ba3052833ae4c-- From nobody Thu Dec 31 09:43:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F2E1A8944 for ; Thu, 31 Dec 2015 09:43:44 -0800 (PST) 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 EGwCHIZSi7GC for ; Thu, 31 Dec 2015 09:43:43 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CDF91A8943 for ; Thu, 31 Dec 2015 09:43:42 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id p187so223832110qkd.1 for ; Thu, 31 Dec 2015 09:43:42 -0800 (PST) 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=fnZM8elD1GBCSEP6CID+KjF7gp8aX/74V4eo8CDzftY=; b=ofMIhpemGKsx9F1JWRA0iuqimyfeTyJ+dK5uyZBFPflSKoOphZZtYjK36RjfymTa0k gookVc/ZXBTldQS88HnZHMYPu1OWVgG2BtbM2FXny7SjdXjhD4+RjZrpWRI97Ahz1co5 LwG1qrkgokr10EVg7vsJSzaTJdkaRS+m98x1XUvGty4p43gjNhEj+VG/wVdJJxqQJD6Z /jGIzGvZbblgz+gHU9tO6UsDeW77WpBjTbzjF5YN1npzTknxOnVCWaD0LOrvvLpLRUVG 93UF2/VuQ3KekSjNNXacNCyDLBwh3jIYLJuvrdX4Z3ff8KOrZEgyYA29qTQtO30pd1Gc J7HA== MIME-Version: 1.0 X-Received: by 10.55.74.200 with SMTP id x191mr93331932qka.28.1451583822208; Thu, 31 Dec 2015 09:43:42 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.93.12 with HTTP; Thu, 31 Dec 2015 09:43:42 -0800 (PST) In-Reply-To: References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> Date: Thu, 31 Dec 2015 09:43:42 -0800 X-Google-Sender-Auth: 49_9QExY-7il4M9Ulby5X0Q8i_0 Message-ID: From: Adam Langley To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Karthikeyan Bhargavan , "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 17:43:44 -0000 On Wed, Dec 30, 2015 at 7:40 PM, Brian Smith wrote: > When you say "the plan," whose plan are you referring to? If you read that > whole thread, there was a lot of well-founded opposition to that plan. And, > that plan was never carried out. That is plain to see, as there was never a > draft submitted with such a change. I'm no expert on IETF processes but the draft was already in a late stage at the time when that came up and I think it was last the point for a -12? The revision that's currently in AUTH48 with the RFC Editor contains the change from MUST to MAY. > Not if the implementation doesn't implement RSA or finite-field DH. I think ekr's post, just previous, reflects my understanding here. For the vast majority of implementations, session-hash is needed because non-contributory key-exchange mechanisms will be included. If you do happen to have an implementation that only implements ECDHE with cofactor 1 curves or X25519 or X448, then I guess you could get away without implementing session hash, but I'd still implement session hash anyway. Having said that, I think I'd be fine with a TLS draft that said that the zero check should (or must) be done because I think that it should be done in general. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu Dec 31 09:51:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBBF1A8957 for ; Thu, 31 Dec 2015 09:51:23 -0800 (PST) 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, HTML_MESSAGE=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 pPYHvCoihVeH for ; Thu, 31 Dec 2015 09:51:21 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 714581A894E for ; Thu, 31 Dec 2015 09:51:18 -0800 (PST) Received: by mail-yk0-x229.google.com with SMTP id k129so162295143yke.0 for ; Thu, 31 Dec 2015 09:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=THt4cOCBPKSXFFRFInPpIq2dW9cshSIj9Xtz0iLW5o4=; b=EQwPFDwKSqKA14AWmFkws2fkfULMh/Qsy0KQEOVWdnylLE1SxRAqrqI2z6N+1pE1+F BAuhN8wp9ate09ZjHbfWlUu8SGEcg8SQPUKp53UEKG59gVVZWbX9hweURjf8Oot4JdL4 qbb+D48OzHmLATzrEWyvrbcAykt+Gr6DmgT9qImYlCJ7rPgFUxvTU2kqAfihhSDrOGEG f2PwzfXLPpS0T41Zbx8eBFBLo9gklHYM4/nc10h52sh9sEUtx2PTZy9mmlwhmAuKuZuZ iCE+3o2mI+aIuMPTl2NQfO5UdQwF913FRKhOo1tDQy6folWmWrIIwh0pGc+qbQ6i2Bbo J7Lg== 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=THt4cOCBPKSXFFRFInPpIq2dW9cshSIj9Xtz0iLW5o4=; b=JqsuTJUlkGYplqbgRSpG4kw0gqDvcdcR8Pvyn4SgOXn4L0+rcIoRgeVqdIewQgey4w 8gXELpdHqiUuZnbg4qfB4zhCzogX4szKKr/Hmye46/xIwppYdux0iwsOzKqZa3EZ6K7m Aaapxkr+9129oj+IEAoMfoetPXQCD+wT56vFAIQ67XgM1OWVz9pN7puNIRhn1vwwmldH Uw7m8YfmseXf1rnjAx0XcxxcnpV06z0bPvyzXKWRdJDgbFQQJqgDSTOPj7OsZGFUL6Yn u37wLbVlqazv5zjH4ukmyPZBbY0f/rnuxLRpQLF3iOSo3T2eEWmcxH5YNgFEBFkBhFOS xVxw== X-Gm-Message-State: ALoCoQkEhISX8Aje4gNF1NeGi/WdBwZf0XWLt3kr7SUuUmTzwsUCtdovPCd3RJLZABO+7oAvDn+Za069LnnA12kJhPbtpNN3aw== X-Received: by 10.129.46.208 with SMTP id u199mr52122992ywu.129.1451584277720; Thu, 31 Dec 2015 09:51:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Thu, 31 Dec 2015 09:50:37 -0800 (PST) In-Reply-To: References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> From: Eric Rescorla Date: Thu, 31 Dec 2015 09:50:37 -0800 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=001a114085923c5c810528354dc1 Archived-At: Cc: Karthikeyan Bhargavan , "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 17:51:23 -0000 --001a114085923c5c810528354dc1 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 31, 2015 at 9:43 AM, Adam Langley wrote: > On Wed, Dec 30, 2015 at 7:40 PM, Brian Smith wrote: > > When you say "the plan," whose plan are you referring to? If you read > that > > whole thread, there was a lot of well-founded opposition to that plan. > And, > > that plan was never carried out. That is plain to see, as there was > never a > > draft submitted with such a change. > > I'm no expert on IETF processes but the draft was already in a late > stage at the time when that came up and I think it was last the point > for a -12? The revision that's currently in AUTH48 with the RFC Editor > contains the change from MUST to MAY. > > > Not if the implementation doesn't implement RSA or finite-field DH. > > I think ekr's post, just previous, reflects my understanding here. For > the vast majority of implementations, session-hash is needed because > non-contributory key-exchange mechanisms will be included. If you do > happen to have an implementation that only implements ECDHE with > cofactor 1 curves or X25519 or X448, then I guess you could get away > without implementing session hash, but I'd still implement session > hash anyway. > FWIW, I don't believe that it's significantly harder to implement TLS w/ session hash than TLS w/o session hash. You have to do the extension but since you can just fail any handshake in which it's not offered, this isn't that bad. What's expensive is supporting *both* session hash and non session hash (at least that's what we found in NSS). Having said that, I think I'd be fine with a TLS draft that said that > the zero check should (or must) be done because I think that it should > be done in general. > As would I. -Ekr > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114085923c5c810528354dc1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 31, 2015 at 9:43 AM, Adam Langley <agl@imperialviolet= .org> wrote:
On Wed, Dec 30, 2015 at 7:40 PM, Brian Smith <brian@briansmith.org> wrote:
> When you say "the plan," whose plan are you referring to? If= you read that
> whole thread, there was a lot of well-founded opposition to that plan.= And,
> that plan was never carried out. That is plain to see, as there was ne= ver a
> draft submitted with such a change.

I'm no expert on IETF processes but the draft was already in a l= ate
stage at the time when that came up and I think it was last the point
for a -12? The revision that's currently in AUTH48 with the RFC Editor<= br> contains the change from MUST to MAY.

> Not if the implementation doesn't implement RSA or finite-field DH= .

I think ekr's post, just previous, reflects my understanding her= e. For
the vast majority of implementations, session-hash is needed because
non-contributory key-exchange mechanisms will be included. If you do
happen to have an implementation that only implements ECDHE with
cofactor 1 curves or X25519 or X448, then I guess you could get away
without implementing session hash, but I'd still implement session
hash anyway.

FWIW, I don't believe = that it's significantly harder to implement TLS w/ session
ha= sh than TLS w/o session hash. You have to do the extension but since
<= div>you can just fail any handshake in which it's not offered, this isn= 't that bad.
What's expensive is supporting *both* sessio= n hash and non session hash
(at least that's what we found in= NSS).


Having said that, I think I'd be fine with a TLS draft that said that the zero check should (or must) be done because I think that it should
be done in general.

As would I.

-Ekr
=C2=A0

Cheers

AGL

--
Adam Langley agl@imperialviolet.o= rg https://www.imperialviolet.org

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

--001a114085923c5c810528354dc1-- From nobody Thu Dec 31 11:22:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37ED1A8A28 for ; Thu, 31 Dec 2015 11:22:02 -0800 (PST) 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 fdZVX2oAZVDz for ; Thu, 31 Dec 2015 11:22:01 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5AB41A0021 for ; Thu, 31 Dec 2015 11:22:01 -0800 (PST) Received: by mail-ig0-x22e.google.com with SMTP id mv3so163408408igc.0 for ; Thu, 31 Dec 2015 11:22:01 -0800 (PST) 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=9jgz6MesIH1T/wot6bslLu5G1gMSUkIUeJxqoWwgh9I=; b=kdGvunGsbdWBk6dBANBEp2uqb5R0kYNDiP14HVwgcM0kM1sTANsnkX8KDfr4FOXp72 RlfNpaugqlgCck5VLmIklQht4Nm7D94+B6FmOrE3qFI23xlU/iLJ6lfQ71SJXJCJxOZT aoXKTXb8UvGsYdrnn0Nrj+TG4oAts8hBguZtUp9UkxwsXlL4hHjO13OXNp+3c+WQ5evs qlcn10xZ3YDEOFgQ74yE+Exi8kboRVGBfaP/zHbRPSeO4+3aWcidiS6PBgrUlyfVAkZP V4Koi8VpOEiRG6YqxNH4/Oqhqqr7ieBgRszNP4VTpTfX549mumHyORtiHWjNt4o3TfgL HQQA== MIME-Version: 1.0 X-Received: by 10.50.66.179 with SMTP id g19mr52806507igt.94.1451589721119; Thu, 31 Dec 2015 11:22:01 -0800 (PST) Received: by 10.36.149.130 with HTTP; Thu, 31 Dec 2015 11:22:00 -0800 (PST) In-Reply-To: <20151231065451.GA24161@LK-Perkele-V2.elisa-laajakaista.fi> References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> <5684C9CC.2080703@akr.io> <20151231065451.GA24161@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 1 Jan 2016 06:22:00 +1100 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 19:22:03 -0000 On 31 December 2015 at 17:54, Ilari Liusvaara wrote: > Zero checks can already be unit-tested/interop-tested just as well. What ekr said applies, but also this: Yes, you can test that a given implementation does the right checks, but you won't be checking during normal operation. If you require session-hash, then every handshake includes that check and if someone messes up, the handshake just fails. That far more visible. From nobody Thu Dec 31 12:17:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509C41A00D0 for ; Thu, 31 Dec 2015 12:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 TDOGzfR8Hx3Q for ; Thu, 31 Dec 2015 12:17:44 -0800 (PST) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA941A03A3 for ; Thu, 31 Dec 2015 12:17:44 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id tBVKGaRL009539; Thu, 31 Dec 2015 15:17:19 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Alyssa Rowan , "tls@ietf.org" Thread-Topic: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? Thread-Index: AdFECCXz/+qKCFGi70GWkMEmG0pPlA== Date: Thu, 31 Dec 2015 20:16:35 +0000 Message-ID: <20151231201644.17780804.55594.43078@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============0488936153==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2015-12-31_14:2015-12-31,2015-12-31,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1511060000 definitions=main-1512310353 Archived-At: Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 20:17:46 -0000 --===============0488936153== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable I think Watson made a good point about "omittable checks". =E2=80=8EIf an i= mplementation A "omits" this mechanism, it should fail session establishmen= t. Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the Verizon=C2=A0Wireless=C2=A04G=C2=A0LTE=C2=A0network. =C2=A0 Original Message =C2=A0 From: Alyssa Rowan Sent: Thursday, December 31, 2015 01:23 To: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation n= ecessary or helpful? --===============0488936153== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKTM8n7QAAAABB0TANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE1MDYwNTE4MTY0NFoXDTE2MDYwNDE4MTY0NFowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDQ 0ZYk84x0NrbLSMf9w+9rvO8Z3d5dfpynEt9it4HkQ3Fht5wpD1DOICbdPmcuoNGv73LUI6oRn7XT CnAFOeW9dGZetOUBIL44l0BoMYlUOvqOhtXUIoxm6PNbnDsYW3HpNuiskGO+jjH5CrvSFsZ//GHA dMGsQpRNBU7ZHCoOZF7+rv9RUh5pN5OgKumv9p24nWtGHNR1AHHDjB50Df9/1DVGhpe6aqf5DBhe f+1rf/dgAhjFSzrj3lTgNuczkZcB9Xs6fktq1jRCuwCdVTXQ/xgM5I3FHnVP73QEccOFR9qfdEVA 5IT7jo/7hMIvOBMWUJGOP7BpYXJd4VKj8CxLAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUr3pideNu 8mmOhHY8C2sJnlo/HVAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAKVaDwP2SaWtXtIINTrHpvDXC9dslWAv Tfg3TmHrQMtlKM6GQqkgIzF4WMZgM64RyUOqEnXrDcD7a3GPrcf8zDjRnsTiYaGkzhEUb/do5igL Al5x+FwAvhwvEuLJwHpAk0sfbxfX4lxY1S1YUngS+5PXGJbbFaNPAOefDG8jGgaM4TJ1weWlLT8F /MJudL6L6azCfOWQZhxpnT037XWGPeUfuqNnmwkwwlrCQB2QYgLQJtlUZQPqnb8Y2hd6OfhE7qvv /fcvX7i+Q4UKh3xGlMN2QHoX0Sk9sxxc4vgJnKk7MhaufGtOuNJLZlSfzCQRGd9Zprq9M+ROXuwN u72bKQkwggTqMIID0qADAgECAgpMzyftAAAAAEHRMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTUwNjA1MTgxNjQ0WhcNMTYwNjA0MTgxNjQ0WjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANDRliTzjHQ2tstIx/3D72u87xnd3l1+nKcS32K3geRDcWG3nCkPUM4gJt0+Zy6g0a/v ctQjqhGftdMKcAU55b10Zl605QEgvjiXQGgxiVQ6+o6G1dQijGbo81ucOxhbcek26KyQY76OMfkK u9IWxn/8YcB0waxClE0FTtkcKg5kXv6u/1FSHmk3k6Aq6a/2nbida0Yc1HUAccOMHnQN/3/UNUaG l7pqp/kMGF5/7Wt/92ACGMVLOuPeVOA25zORlwH1ezp+S2rWNEK7AJ1VNdD/GAzkjcUedU/vdARx w4VH2p90RUDkhPuOj/uEwi84ExZQkY4/sGlhcl3hUqPwLEsCAwEAAaOCAbIwggGuMB0GA1UdDgQW BBSvemJ1427yaY6EdjwLawmeWj8dUDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEApVoPA/ZJpa1e0gg1Osem 8NcL12yVYC9N+DdOYetAy2UozoZCqSAjMXhYxmAzrhHJQ6oSdesNwPtrcY+tx/zMONGexOJhoaTO ERRv92jmKAsCXnH4XAC+HC8S4snAekCTSx9vF9fiXFjVLVhSeBL7k9cYltsVo08A558MbyMaBozh MnXB5aUtPwX8wm50vovprMJ85ZBmHGmdPTftdYY95R+6o2ebCTDCWsJAHZBiAtAm2VRlA+qdvxja F3o5+ETuq+/99y9fuL5DhQqHfEaUw3ZAehfRKT2zHFzi+AmcqTsyFq58a0640ktmVJ/MJBEZ31mm ur0z5E5e7A27vZspCTCCBO0wggPVoAMCAQICCihwejIAAAAALQcwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNTAxMjMxNzQ5MjlaFw0xNjAxMjMxNzQ5MjlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxfkXLPYTTuYb5RNGHpbanlxlFtbt0VTBuP9moOidhYHLDicTmcv5vuxX mHwqN12Kzasev9yGZg0mJZ9yZ8cz4qJw3GytkyfcQDqFpa1MpAIYFJfjwjvGoQ1eWHNLZjM3+TFw a7Lm9J1MiXg5MTlGNiHefA9VFc814fSr43PmQnAURaFYgIJ+zM557ryvGOZuy6K9aC1ksTTVMqff IAuBKXRy5wPMj9Vqpja9MfmLLIyYBIiH2RasfBr79jqrR2hRh4e2OvljliGVCzGgHPSSRKvHLZ7P ZhiEZXX9iTBXDbGoUCQ4YFLKZj+nNVs/Tq1MbIMJxkOX3iKvXP+GGWBGfwIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFEdIXm5OIutOt2J6RBFV8kFMn0hTMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQA4puc4 02/4d3mv+ugzTOsEpotU4vRdn9vwK3tmu2vRPyD135Xod/ZVRu7k2p3hCTEh8w5bZAeZOg2DL/7d vJ7UJtoyyPWnTMHHA5SkkdriA7IgO46HYk8W6i/2kYvlguMm1loV7s0m5DHrGsreUACqbiiwK+53 sH2WlsfMz51lNZ1mQWyUe3CyoFE2hIkLvzZQliBSSAvckYc3vikeNbyGvu54kJ1ADY6GAgrt9mfM YMYSuJEK+bXlFVDQ6Ao9Nse/NRhX8ApJ8abFhJveTljNYmlyghifHIoqLpRM5LGVKyB3SJiEmkFV fl3Zm3Hdzh+svHzZdZmXV5/LMTSXPv4NMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgpMzyftAAAAAEHRMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTIzMTIwMTYzOVowLwYJKoZIhvcNAQkEMSIEIJU/aVacy8kU 1XYn1iJ+p9Ftqpo9rP/qrDhnyCCR3PG3MAsGCSqGSIb3DQEBCwSCAQCbORwknuWekqBzA/wvy3TK XYe/hsZ+8yZ9cAnCjCBcEcYLPPTBM7iY0QqHdZYtHJXtpxMVJ3zmaBTAB6gMClcLwtjVvZC30EoH d0KIbTla5HGW3OFHPaJ/5nDGWIoY6dptvZH09BfSQTE/FhFQKgmixlgNLVu49YrgJ+2lQoyWcC6p 7pay0VafJBGpges8i0tiP1qmC0ZpvqRxNGMG6EeTQHtAZbXk9dLdtFlc1Q88fXhZOHvCTLrBHIst iQ3y+jfbbaW2xFIbKXtzqENVgr37S+lpf92a7GBgxjbzpCTuwMn8d242JtfzBqFo9tYobuy7VwSH xg4xal66yIyG9UtXAAAAAAAA --===============0488936153==-- From nobody Thu Dec 31 12:20:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A3A1A8A9D for ; Thu, 31 Dec 2015 12:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 TuuSchwiueyl for ; Thu, 31 Dec 2015 12:20:46 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id AE6441A8A94 for ; Thu, 31 Dec 2015 12:20:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 3881C2311; Thu, 31 Dec 2015 22:20:45 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id Jh5nIA-QFfmx; Thu, 31 Dec 2015 22:20:44 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id D336027B; Thu, 31 Dec 2015 22:20:44 +0200 (EET) Date: Thu, 31 Dec 2015 22:20:43 +0200 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20151231202043.GA24791@LK-Perkele-V2.elisa-laajakaista.fi> References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> <5684C9CC.2080703@akr.io> <20151231065451.GA24161@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 20:20:49 -0000 On Fri, Jan 01, 2016 at 06:22:00AM +1100, Martin Thomson wrote: > On 31 December 2015 at 17:54, Ilari Liusvaara wrote: > > Zero checks can already be unit-tested/interop-tested just as well. > > > What ekr said applies, but also this: I thought the ekr's point was that if you need THS resistance, you require EMS. If you don't, not much point worrying what properties individual key exchanges have. > Yes, you can test that a given implementation does the right checks, > but you won't be checking during normal operation. If you require > session-hash, then every handshake includes that check and if someone > messes up, the handshake just fails. That far more visible. I don't think the parts that actually matter are tested in normal use. Unless you mean deimplementing entiere old TLS master secret derivation... -Ilari From nobody Thu Dec 31 12:24:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76C81A8ACA for ; Thu, 31 Dec 2015 12:24:31 -0800 (PST) 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, HTML_MESSAGE=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 231NgofkhZtQ for ; Thu, 31 Dec 2015 12:24:30 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9044C1A8AC8 for ; Thu, 31 Dec 2015 12:24:30 -0800 (PST) Received: by mail-yk0-x231.google.com with SMTP id a85so109949288ykb.1 for ; Thu, 31 Dec 2015 12:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=da6PGYPq0OF2OKBeoDHc0ERNoEiBuCZtYRoaOU1YmGE=; b=gwCwvBK23loZM+YRy+blYKqAH9Wls8GSKGi1+lrvTqqyGY3gm2AI93F8/cEUjfUmng vyvcHlQ7XUJYJQIIBwF6yadm7+xaN2H0dJVkl8F9pAjovcR4BQiR8quwk/Sf4WBiKz2y IMDlLDyldy8miANdfzhOd3iQeR4fwEkBI08kFygZeHnTk93EIJ19QBPmmZ7escByQRag I0YIE/RUbquTFvMsCMEMMSqjOAyEAPQ7hANLoaCp1OQQHMM3WrZNtyPvusgBnYaUgzr0 scW8riCgSSR8T1pQmWZEYGK0ekwwzjfBHWij2TTcvtmVCrSXkyxRTV1fCPiW5HNrQ4/s yf4g== 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=da6PGYPq0OF2OKBeoDHc0ERNoEiBuCZtYRoaOU1YmGE=; b=EG5SUNw7tIinJl+nGXBrzwxwDl3yZ+JjuGMja6O8MOSMKiDCrG6jGXMKpTKUCIrQSU DhhXYwnDSFZPF0t854buQT6wktcYImI/iqXYkSoi0dKbjtvWS47vXEG0a3YvyMFuYUHD h/5HdzW6bPNGbBbW7nIX3EivDZCcUP0HAnxv/9TDfVRvtvDyIJMsjlC66bU7sxpu3mOH lRFwOhNDXjBr4hEehVm61m0pF77j4lJeWlHKBmDut0K4l2pHPg5/IPBfgElPsERfVwWo /BuDovIjJsH3wdaQDsyeGOziSHswlt9guYKW3drvxslP1iGUA+PWH/WnLcC/daP0lArK jfqw== X-Gm-Message-State: ALoCoQmbxp2voEbApP4JWpGrjwaar8TLc/6GfQeOC0Bq1fwTpwLlffivlRknvGqOo7SAt2P3qWE2y67Zht6Phf2skjr7CDqJvg== X-Received: by 10.129.153.3 with SMTP id q3mr60233808ywg.231.1451593469756; Thu, 31 Dec 2015 12:24:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Thu, 31 Dec 2015 12:23:50 -0800 (PST) In-Reply-To: <20151231202043.GA24791@LK-Perkele-V2.elisa-laajakaista.fi> References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> <5684C9CC.2080703@akr.io> <20151231065451.GA24161@LK-Perkele-V2.elisa-laajakaista.fi> <20151231202043.GA24791@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Thu, 31 Dec 2015 12:23:50 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c0bbfae1fce5e05283771d0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 20:24:32 -0000 --94eb2c0bbfae1fce5e05283771d0 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 31, 2015 at 12:20 PM, Ilari Liusvaara wrote: > On Fri, Jan 01, 2016 at 06:22:00AM +1100, Martin Thomson wrote: > > On 31 December 2015 at 17:54, Ilari Liusvaara > wrote: > > > Zero checks can already be unit-tested/interop-tested just as well. > > > > > > What ekr said applies, but also this: > > I thought the ekr's point was that if you need THS resistance, you > require EMS. If you don't, not much point worrying what properties > individual key exchanges have. > I think I was trying to say *almost* this: Namely that given that we have existing mechanisms that rely on EMS for THS resistance, and most stacks will continue to use them, then it's easier to just require EMS. > Yes, you can test that a given implementation does the right checks, > > but you won't be checking during normal operation. If you require > > session-hash, then every handshake includes that check and if someone > > messes up, the handshake just fails. That far more visible. > > I don't think the parts that actually matter are tested in normal > use. Unless you mean deimplementing entiere old TLS master secret > derivation... What I was suggesting was that: 1. Implementations which support old algorithms need to have EMS for THS resistance already. 2. Implementations which only do new algorithms can mandate EMS and not implement old derivation at all, provided we make that a rule here. -Ekr --94eb2c0bbfae1fce5e05283771d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 31, 2015 at 12:20 PM, Ilari Liusvaara <= ;ilariliusvaa= ra@welho.com> wrote:
On Fri, Jan 01, 2016 at 06:22:00AM +1100, Martin Thomson wrote:<= br> > On 31 December 2015 at 17:54, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> > Zero checks can already be unit-tested/interop-tested just as wel= l.
>
>
> What ekr said applies, but also this:

I thought the ekr's point was that if you need THS resistance, y= ou
require EMS. If you don't, not much point worrying what properties
individual key exchanges have.

I think = I was trying to say *almost* this: Namely that given that we have existing<= /div>
mechanisms that rely on EMS for THS resistance, and most stacks w= ill continue
to use them, then it's easier to just require EM= S.


> Yes, you can test that a given implementation does the right checks, > but you won't be checking during normal operation.=C2=A0 If you re= quire
> session-hash, then every handshake includes that check and if someone<= br> > messes up, the handshake just fails.=C2=A0 That far more visible.

I don't think the parts that actually matter are tested in norma= l
use. Unless you mean deimplementing entiere old TLS master secret
derivation...

What I was suggesting was tha= t:

1.=C2=A0 Implementations which support old algo= rithms need to have EMS for THS
resistance already.
2. Implementations which only do new algorithms can mandate EMS= and not
implement old derivation at all, provided we make that a= rule here.

-Ekr

<= /div> --94eb2c0bbfae1fce5e05283771d0-- From nobody Thu Dec 31 12:46:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD9B1A8AE5 for ; Thu, 31 Dec 2015 12:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 aMQgiJlYN_f7 for ; Thu, 31 Dec 2015 12:46:07 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 93D9F1A8AE4 for ; Thu, 31 Dec 2015 12:46:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 827DE17A; Thu, 31 Dec 2015 22:46:06 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 93ZTfdAGg-vQ; Thu, 31 Dec 2015 22:46:06 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 1A1C4230D; Thu, 31 Dec 2015 22:46:06 +0200 (EET) Date: Thu, 31 Dec 2015 22:46:05 +0200 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20151231204604.GB24791@LK-Perkele-V2.elisa-laajakaista.fi> References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> <20151230111631.GB23341@LK-Perkele-V2.elisa-laajakaista.fi> <20151231000803.GA23937@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: Karthikeyan Bhargavan , "" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 20:46:09 -0000 On Wed, Dec 30, 2015 at 09:16:12PM -0500, Watson Ladd wrote: > On Wed, Dec 30, 2015 at 7:47 PM, Brian Smith wrote: > > Watson Ladd wrote: > > > > Actually, because the check for non-zero result can/should/is in the > > X25519/X448 functions themselves, the check for non-zero result is the least > > likely of all these possible solutions to be omitted. And, it is also the > > easiest to test. > > Failure to compute H(A, B, X25591(a, B)) would result in an > interoperability failure with any other implementation of this > ciphersuite. By contrast a zero check will not be exercised by basic > interoperability testing, nor would mandatory use of session hash. Actually, I figured out an attack. Which also breaks my original scheme (except in one rare case). A hack to break that attack would be to zero-pad the hash output to minimum of 48 bytes and then to append (prepending won't work) something nonzero (e.g the group id, that is 00 29 for X25519 and 00 30 for X448). -Ilari From nobody Thu Dec 31 12:50:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117B31A8AEB for ; Thu, 31 Dec 2015 12:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 q7zVcah92WhH for ; Thu, 31 Dec 2015 12:50:00 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC821A8AEA for ; Thu, 31 Dec 2015 12:50:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 76F851A5; Thu, 31 Dec 2015 22:49:59 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id iIIMACwJBTod; Thu, 31 Dec 2015 22:49:59 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 419742310; Thu, 31 Dec 2015 22:49:59 +0200 (EET) Date: Thu, 31 Dec 2015 22:49:58 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20151231204958.GC24791@LK-Perkele-V2.elisa-laajakaista.fi> References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> <5684C9CC.2080703@akr.io> <20151231065451.GA24161@LK-Perkele-V2.elisa-laajakaista.fi> <20151231202043.GA24791@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 20:50:02 -0000 On Thu, Dec 31, 2015 at 12:23:50PM -0800, Eric Rescorla wrote: > On Thu, Dec 31, 2015 at 12:20 PM, Ilari Liusvaara > wrote: > > 2. Implementations which only do new algorithms can mandate EMS and not > implement old derivation at all, provided we make that a rule here. Well, the EMS spec already says that endpoints SHOULD abort if extension is not present if they don't want to interop with legacy implementations. -Ilari From nobody Thu Dec 31 12:55:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16171A8AFA for ; Thu, 31 Dec 2015 12:55:50 -0800 (PST) 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, HTML_MESSAGE=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 LFqGTzrJj5kZ for ; Thu, 31 Dec 2015 12:55:50 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F051A8AF8 for ; Thu, 31 Dec 2015 12:55:49 -0800 (PST) Received: by mail-yk0-x233.google.com with SMTP id v14so94383390ykd.3 for ; Thu, 31 Dec 2015 12:55:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/m6fs+jDOwnqdY0Ay8tglDYlMdxs69kGMdt4wqVD4Hk=; b=iamJnrVKNDPMSnTeHYhZe9/2cC/llIjOPS7DYlGOtCno0Wr+ztVBjgYR8ANUa3trak 7F6K+mo6Br4zqtMIFQlLqsNo6FIqPCo7s/LvaXKTbkyyB2ISerTiB72JFGxgML4LNZ0q SA8Ez0sY8MqKmnyKw/4zjXzjePKIvAlW5p7jeX5r2Iz3swtDf3wFMnUIGJLimrMmy6z2 uqXhEppMt8znh6Rv6VRgvAcV2TD9q/7ygQSuhrVCMpPzw08ZWIcdmRIURYsoyUHwZqBD Avuj/G1DoNB7pWRyvn5uu6lc6mmTgBFGTqmwRn78Twz+rpk4pHvA5sBAdRG+rcnH/Fwl 5CkA== 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=/m6fs+jDOwnqdY0Ay8tglDYlMdxs69kGMdt4wqVD4Hk=; b=Z44VpYH/ZLKubCx5X6pU43as2s1YsPyvFJYGoPZGzxxwZaICnepJl2SIAVVf98ujh0 sgtQgdaloAYxoJ5s02tQkwki1+ZHEP4bfddRu0EdWtI1SAL6MIrGmjCZegEkP3c533fl RufnISc+ozm4FSgUXS+6T1fdU+EisZmzdFJe2B44z6pK3WmwDDF4ZY8gnTSXk+MgcUB+ Y0qMFCNWngKNDDnZ2vy6cLrvP0GrKUYl+3fqUEwpg9upAozB99hIHncgwE0A1YwMYKY3 oziiBLpxhvjgOIBysYTC03Lhz13wMht4Uqjhtywg+IjRuSdog3161M4UR0T9XaRixfMX OnQg== X-Gm-Message-State: ALoCoQl9vof7BdQSJCWcNRRj1ptWOB/lvJB3K17LQccPC84Qw8LE1m92DIP5dUbZO9YekY2UzNwGOvsBg3WzLlM9uS6MSqKPDA== X-Received: by 10.129.148.3 with SMTP id l3mr53529075ywg.155.1451595348712; Thu, 31 Dec 2015 12:55:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Thu, 31 Dec 2015 12:55:09 -0800 (PST) In-Reply-To: <20151231204958.GC24791@LK-Perkele-V2.elisa-laajakaista.fi> References: <6F6EDAA8-15F2-4949-B927-4D0BD0E8FFE3@inria.fr> <20151230105207.GB6140@roeckx.be> <5684C9CC.2080703@akr.io> <20151231065451.GA24161@LK-Perkele-V2.elisa-laajakaista.fi> <20151231202043.GA24791@LK-Perkele-V2.elisa-laajakaista.fi> <20151231204958.GC24791@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Thu, 31 Dec 2015 12:55:09 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c07c8bc1e4c61052837e10b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 20:55:51 -0000 --94eb2c07c8bc1e4c61052837e10b Content-Type: text/plain; charset=UTF-8 On Thu, Dec 31, 2015 at 12:49 PM, Ilari Liusvaara wrote: > On Thu, Dec 31, 2015 at 12:23:50PM -0800, Eric Rescorla wrote: > > On Thu, Dec 31, 2015 at 12:20 PM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > 2. Implementations which only do new algorithms can mandate EMS and not > > implement old derivation at all, provided we make that a rule here. > > Well, the EMS spec already says that endpoints SHOULD abort if > extension is not present if they don't want to interop with > legacy implementations. Correct. But as you say, that's a check that you can omit. However, if you only implement the EMS derivation than (unless I'm missing something) even if you omit the check this should just result in a handshake failure. -Ekr > > -Ilari > --94eb2c07c8bc1e4c61052837e10b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 31, 2015 at 12:49 PM, Ilari Liusvaara <= ;ilariliusvaa= ra@welho.com> wrote:
On Thu, Dec 31, 2015 at 12:23:50PM -0800, Eric Rescorla wrote: > On Thu, Dec 31, 2015 at 12:20 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> 2. Implementations which only do new algorithm= s can mandate EMS and not
> implement old derivation at all, provided we make that a rule here.
Well, the EMS spec already says that endpoints SHOULD abort if
extension is not present if they don't want to interop with
legacy implementations.

Correct. But as you= say, that's a check that you can omit. However, if you only
= implement the EMS derivation than (unless I'm missing something) even i= f you
omit the check this should just result in a handshake failu= re.

-Ekr
=C2=A0




-Ilari

--94eb2c07c8bc1e4c61052837e10b-- From nobody Thu Dec 31 13:47:12 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3101A88A1 for ; Thu, 31 Dec 2015 13:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 1N4G8UI0u_-o for ; Thu, 31 Dec 2015 13:47:08 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 816E11A889F for ; Thu, 31 Dec 2015 13:47:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 6B85813E; Thu, 31 Dec 2015 23:47:06 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id fY1dSq_j4-iN; Thu, 31 Dec 2015 23:47:06 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 0FA4E230D; Thu, 31 Dec 2015 23:47:06 +0200 (EET) Date: Thu, 31 Dec 2015 23:47:05 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20151231214704.GA24931@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151230105207.GB6140@roeckx.be> <5684C9CC.2080703@akr.io> <20151231065451.GA24161@LK-Perkele-V2.elisa-laajakaista.fi> <20151231202043.GA24791@LK-Perkele-V2.elisa-laajakaista.fi> <20151231204958.GC24791@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Dec 2015 21:47:10 -0000 On Thu, Dec 31, 2015 at 12:55:09PM -0800, Eric Rescorla wrote: > On Thu, Dec 31, 2015 at 12:49 PM, Ilari Liusvaara > wrote: > > > On Thu, Dec 31, 2015 at 12:23:50PM -0800, Eric Rescorla wrote: > > > On Thu, Dec 31, 2015 at 12:20 PM, Ilari Liusvaara < > > ilariliusvaara@welho.com> > > > wrote: > > > > > > 2. Implementations which only do new algorithms can mandate EMS and not > > > implement old derivation at all, provided we make that a rule here. > > > > Well, the EMS spec already says that endpoints SHOULD abort if > > extension is not present if they don't want to interop with > > legacy implementations. > > > Correct. But as you say, that's a check that you can omit. However, if you > only > implement the EMS derivation than (unless I'm missing something) even if you > omit the check this should just result in a handshake failure. Yes, if you don't want to interop with legacy implementations, don't implement the legacy key derivation. Unfortunately, I think I figured out that client requiring ECDHE even with only NIST curves with full checking (which is contributory if that is even possible) does _not_ prevent THS attacks. So, if the protocol run on TLS does not resist THS attacks anyway somehow, you MUST require EMS. -Ilari From nobody Thu Dec 31 22:35:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2046D1A1A60 for ; Thu, 31 Dec 2015 22:35:35 -0800 (PST) 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] 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 IxLctpdKx8yq for ; Thu, 31 Dec 2015 22:35:33 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244ED1A1A34 for ; Thu, 31 Dec 2015 22:35:33 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id l65so100033418wmf.1 for ; Thu, 31 Dec 2015 22:35:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=REE2nDTmUUFD81bBxStxPttB8efwrWiJSxyF+HOzb0w=; b=jU0pwtC0uaue3Yy7/1G18f+UI9g7+KAkXIPnxJLjV6lsK3PvjORJhE0BNA9ZlL54IY knLuPcxMvZ7QiyvOVIslnKcBhS0DoWO39Zftcv/qdJmGXDOIWUtSTfcOrOnT1uyc9zB5 SJmUACq9PQW7JkUIF8Hj0Qa0A1db7IEn9uVg8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=REE2nDTmUUFD81bBxStxPttB8efwrWiJSxyF+HOzb0w=; b=HJChtxrKKUp7O/l6bbXLqnnhzlo1ZgEJRCdXaYeKpuR/m5fMUW4Aw0JsROHvLp+KRX 1ab+yiKMm3aLgP7DGbvy1xgp0qcANHxvDnB+/wLFPzoLZqBCoPue35bIjWI8/ASKHQyt ST/g1QD63hlaUaNp/dL7esYhNQszSH6HpNjphvGl3i5n5ukrVLS2J8D8QFx5qEhvbVEM Egm2IprhCnOdTRVs2KaV4VfWI9W+iix8tgKPZhDFvIQlIrjOYwFtLZ2EVhIlVk5/vDvK p00OcQNwoUNczxlhTeDVwtgjd/3PlcQKEcqV9NI5xLwQOnpKEDGWHfrwMmOLYvyLWsPn nSDA== X-Gm-Message-State: ALoCoQmvBCPktJ57bKySHUkGhOcgHtRDqDer72UFlmh5YDY07e/dFrbNQ7kluIcVoSHtqdYxFkf2itAvsGCvt8sKNZiR+yZZ7A== X-Received: by 10.194.120.226 with SMTP id lf2mr79672748wjb.108.1451630131618; Thu, 31 Dec 2015 22:35:31 -0800 (PST) Received: from typhoon.azet.org (chello080108049181.14.11.vie.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id u4sm72059095wjz.4.2015.12.31.22.35.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Dec 2015 22:35:30 -0800 (PST) Date: Fri, 1 Jan 2016 07:35:41 +0100 From: Aaron Zauner To: Simon Josefsson Message-ID: <20160101073508.4dd10442c5@ebeb88ce88adeb8> References: <87twnibx5p.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <87twnibx5p.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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, 01 Jan 2016 06:35:35 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, * Simon Josefsson [16/12/2015 09:44:55] wrote: > I don't like re-keying. It is usually a sign that your primitives are > too weak and you are attempting to hide that fact. To me, it is similar > to discard the first X byte of RC4 output. >=20 > If AES-GCM cannot provide confidentiality beyond 64GB (which would > surprise me somewhat), I believe we ought to be careful about > recommending it. >=20 I unequivocally concur here. This might be a good time to point again to my existing AES-OCB draft that hasn't really seen a lot of discussion nor love lately. It expired but I've recently updated the draft (not yet uploaded to IETF as I'm waiting for implementer feedback from two particular sources). The update has something to do with how GCM is implemented in some stacks though, see: https://github.com/azet/draft-zauner-tls-aes-ocb/commit/26c2fff7808fc88bf47= e5d097f2ff5ca23201029 Aaron --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWhh47AAoJEOTbZJL9ubXVU0QP/0tqJ0tZoo8VK1vYwMXqOMCw QNoGB10JDZi+orF6gfYV3+NjtpDm7SpfdbIPlUpZNqYvAErscDhRqbw0wdFGvURb 1Py5KmLHG63axKkHoinNRtIchgEHOlnuacl4AxRp48JpgHElJESgj5urLe8H8NbG iqFaNFnIKdtvJR7HO8brhEtJQ3fDvpQKJJ449VpC568wala2LrjX9VnP8Kf8fyzY xwXHBh+RMgKyMtPJwP8BseHZSuTX8u0MwTgv+jCtYyrv5k9uPtbufIQ/RqTkJBrw wi/a8Aa81F0S8oA8jFfrkvw7h7gaYUzC1zV/LM5OKqX0prqgBhp047D4wZFr0y5m bd9rC2nwZG9lEvqtUk8Bx0XuPVFqyHwbylruJ/bIEy7ggdRRdZKZubcAJD/s+Hn3 OGEfblIQifmgAsntjjsRcCppyoSJ9SAPSijTIgoYk6szbRMkIbBPvr9EcoJtmyZL nMWndYSsZT/A1QOJHkm1V6XnJUgXljSUErPBIzwUlZkP8UvjOS9n2HIJQZOJlTUI POlUllEGVJBUYHG2YaXdA7jTt8NCSlznyV12uOVCC46M1U5Ma48OaloKXaDygoKd XkC8ns7eTuaPA1DFH10XfSaKfb3bHxQiHSM2w/uZ6RpTM0Duvq1hCmaMcR+MtSkh J87YO1fNRVef8YTGwBq9 =5CDl -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From nobody Thu Dec 31 23:04:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF071A6F03 for ; Thu, 31 Dec 2015 23:04:04 -0800 (PST) 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] 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 NsFjpzAD-8xz for ; Thu, 31 Dec 2015 23:04:03 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF83E1A6F04 for ; Thu, 31 Dec 2015 23:04:02 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id f206so130597853wmf.0 for ; Thu, 31 Dec 2015 23:04:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=p/3f/AHgaVl72B8iD0wMV/7PHqCvKDo4/NWDcjDJpdQ=; b=ILTu283xFSQ3MxpVP/z07slvCS3C6KgY9IzxEURJNtGJlLqLEJTtS3fxAzUpJVGUU8 P4sxgt3N3Km7+JhJefF74QO/u7T5Ww0xSiC0ZEUKp+sm8yTjGlzawUFy1JdyYkop6Cie /Jbtj/d49qWZM3CeWxCdMM0oTIo5o7euSf57U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=p/3f/AHgaVl72B8iD0wMV/7PHqCvKDo4/NWDcjDJpdQ=; b=LoINjabiQuKt+6npDygQ5p2XZKZN19VHL+Ehiw+Rz1+qxHjeuIEBHrd9+WikXuCGQK /wzc6TH/8+XY8ZiFjwQm/PxVS3QL+p7x2GL5PUb08i+AsJntCIGw62mBQsbZvuFxKQoF xldGmWufurzL6tvYZ1wALG84aZ7jvoRhfa/vrtHN8rJQ2hQEww+CMCjhQeoAS9B1tXyx QFOdUVZNntrOdgwTGiiN3Z4ZDQdQuCVnxoO68+SP1iz2K/QlCXNp4YD+76XwmT2OPHPp lMWAUvmmfG0+dzeUMnMyolUPksGGcjzvNdFCNvH/aP/vqjV/ceOe0ICSLtwJcRfAruS2 7lDw== X-Gm-Message-State: ALoCoQlX0X0cUiuHBalM5rC51wL3lWzcQgHAzoDySzI9pPhfAQftc/itRsIpSCQl6ClFppb0JafFfitH8HxukZbsWXiWJaWYeQ== X-Received: by 10.28.13.138 with SMTP id 132mr87105820wmn.62.1451631841182; Thu, 31 Dec 2015 23:04:01 -0800 (PST) Received: from typhoon.azet.org (chello080108049181.14.11.vie.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id jm4sm72299431wjb.7.2015.12.31.23.03.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Dec 2015 23:03:59 -0800 (PST) Date: Fri, 1 Jan 2016 08:04:11 +0100 From: Aaron Zauner To: Simon Josefsson Message-ID: <20160101080140.eb268bd207@ad0158c32e55ba2> References: <87twnibx5p.fsf@latte.josefsson.org> <20160101073508.4dd10442c5@ebeb88ce88adeb8> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <20160101073508.4dd10442c5@ebeb88ce88adeb8> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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, 01 Jan 2016 07:04:04 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=utf-8 Content-Disposition: inline * Aaron Zauner [01/01/2016 07:35:26] wrote: > This might be a good time to point again to my existing AES-OCB > draft that hasn't really seen a lot of discussion nor love lately. > It expired but I've recently updated the draft (not yet uploaded > to IETF as I'm waiting for implementer feedback from two particular > sources). The update has something to do with how GCM is implemented > in some stacks though, see: > https://github.com/azet/draft-zauner-tls-aes-ocb/commit/26c2fff7808fc88bf47e5d097f2ff5ca23201029 Having said that, it's probably also a good idea for me to mention that the OCB designers point out that: ``` [...] Birthday-bound attacks (as well as good cryptographic hygine) motivate rekeying well in advance of birthday-bound concerns. In RFC 7253 we say that a given a key should be used to encrypt at most 248 blocks (about 280 terabytes). ``` -- http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#ferguson Aaron --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWhiTpAAoJEOTbZJL9ubXVfVYP/3W4hrGPQmdgdV6V722V1unX 7Wn70NOZxpIcDa7y78wY/jNm0ztDU+JwdRibd01qwWdL4vszsf+ik9nGPTvQCO8G JqLAsOA9NDwR8vUzMAFLwZt/np8pXGhTU4LEk6+kHBU4sMDr56gZTfOm8ogYsXUx Zyfl8jO7mv7NcIaFgHxe94RPBV7O+g+RYBMkm13kQEACg3meWNQgTCl0AYPI/RFS TS2tXRdvlUdVyAHZCqOiaMjqr16/U0fu5U/84SAINMeTjhGQ+FpvUzpGULNwcI+V XJBjwaSTYzAt4wEaHvqrCTeCldJ+hJfoltkHzLaITXQR7UzxPAvxLgja922iTYe9 Qmkcn2iqZdKDGz8aCY25pFZK2zHFM0vhnratUQwJySWps8vTJ2mJ59Iar8FD0mYP xXiPWI6yqPtK5c5UqDWcUJi38f2vLvcJMJUNQC3udsuCp7yrjIZyV9mcpzVe0jS8 la/RfUlhtbSWjo+wcE8hJPlAQCFLMYfHew49cfeENx616RpU0FtaJ7VwORy/Vev3 n3nB0INjiVJB/33mgaGsSp4lva5ZYTvIotz1eSAjd/TNKdGbKnwRgPSLK/FdJa88 ZHzzRO4eUYJCHvUnFeZlfcNa35W+7c7UkwWfj8ENQyRIfSITB5qOWzIVzVPiEEiT YisfMkZJAXtvG6YMAi44 =daqZ -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From nobody Thu Dec 31 23:23:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C6E1A6F3F for ; Thu, 31 Dec 2015 23:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 zxapltjyetcR for ; Thu, 31 Dec 2015 23:23:34 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 44D281A6F3E for ; Thu, 31 Dec 2015 23:23:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id E171C22C3; Fri, 1 Jan 2016 09:23:32 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id R82JSUPBuWiS; Fri, 1 Jan 2016 09:23:32 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 791A1230D; Fri, 1 Jan 2016 09:23:32 +0200 (EET) Date: Fri, 1 Jan 2016 09:23:31 +0200 From: Ilari Liusvaara To: Aaron Zauner Message-ID: <20160101072330.GA25277@LK-Perkele-V2.elisa-laajakaista.fi> References: <87twnibx5p.fsf@latte.josefsson.org> <20160101073508.4dd10442c5@ebeb88ce88adeb8> <20160101080140.eb268bd207@ad0158c32e55ba2> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160101080140.eb268bd207@ad0158c32e55ba2> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data volume 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, 01 Jan 2016 07:23:36 -0000 On Fri, Jan 01, 2016 at 08:04:11AM +0100, Aaron Zauner wrote: > * Aaron Zauner [01/01/2016 07:35:26] wrote: > > This might be a good time to point again to my existing AES-OCB > > draft that hasn't really seen a lot of discussion nor love lately. > > It expired but I've recently updated the draft (not yet uploaded > > to IETF as I'm waiting for implementer feedback from two particular > > sources). The update has something to do with how GCM is implemented > > in some stacks though, see: > > https://github.com/azet/draft-zauner-tls-aes-ocb/commit/26c2fff7808fc88bf47e5d097f2ff5ca23201029 > > Having said that, it's probably also a good idea for me to mention > that the OCB designers point out that: > ``` > [...] > > Birthday-bound attacks (as well as good cryptographic hygine) > motivate rekeying well in advance of birthday-bound concerns. In RFC > 7253 we say that a given a key should be used to encrypt at most 248 > blocks (about 280 terabytes). > ``` -- http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#ferguson > > Aaron On topic of existing recomendations, SECSH recommends rekeying after 2^32 blocks (64GB) with 128-bit block ciphers like AES[1]. This is obviously a lot more conservative than the above quoted recommendation. Also, it occurs to me that if key update makes sense to even include depends on the decided threshold. If it is 64GB, then it makes sense to include. If it is 256TB, then probably not (pseudo- wrapping TLS sequence numbers is probably not a good usecase, as data volumes would need to be enormous for that to become an issue). [1] It also has recommendation to rekey before 2^32 packets, but that comes from SSH sequence numbers being 32-bit. TLS sequence numbers are 64-bit. -Ilari