From nobody Wed Jun 1 07:41:15 2016 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 4D0F112D5A2; Wed, 1 Jun 2016 07:41:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160601144113.16073.53634.idtracker@ietfa.amsl.com> Date: Wed, 01 Jun 2016 07:41:13 -0700 Archived-At: Cc: tls@ietf.org, tls-chairs@ietf.org Subject: [TLS] tls - New Meeting Session Request for IETF 96 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 14:41:13 -0000 A new meeting session request has just been submitted by Joseph A. Salowey, a Chair of the tls working group. --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: J. Salowey Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: tokbind tcpinc stir saag rtcweb httpauth httpbis dane cfrg cose acme uta curdle Second Priority: sacm oauth Special Requests: --------------------------------------------------------- From nobody Wed Jun 1 15:29:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAD212D0CE for ; Wed, 1 Jun 2016 15:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKt5T3TmrOF5 for ; Wed, 1 Jun 2016 15:29:17 -0700 (PDT) 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 7C21F12D0C7 for ; Wed, 1 Jun 2016 15:29:17 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id p194so31085773iod.1 for ; Wed, 01 Jun 2016 15:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=PRUWT+7HkgtHfVvLqyiWbzlDcZEbjY3W+KkTwzONBpM=; b=d/oA/q6CCgUVFG+QUuLLiaRiQJ8g/Guj+LOlNga/f4C3tqaLfNrAqV4DG5f4ETEqMg rqAv6/BziUmqLEtMlZkfqiKx8ptqtrs+VoNFgVbqZW1mJ3VecBrBC9G9cSZIX7SOXFJ2 exe8+Nwf1Z2G78zNikBxbjirUorxPVPlvWkH4= 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; bh=PRUWT+7HkgtHfVvLqyiWbzlDcZEbjY3W+KkTwzONBpM=; b=QSPF44aJr8HJjMJefjvxfQvTHaay07hpiuEgAqsZetWPYdwR5qyqU4OtyMIRrKJxVa iapE7ObRe367f5Xz9114N3KKc1NP/JYBuOnh//Au3RubfBSqYjdIE1+OZvmbFwZtcD3A WJI0OOAX4yS6EZd9Wmn3GOjL2pyHlSEG+p7n84zokKi10Tl9u/R3d418DXbpI2PtwYre sTBakRVY9+fWaSRESIBc/j8SWWUkcK2ot11qgpm6qw7Wh854H0aYROeCNdO1dwV4yKdL TP9Tv+xuI8ho9iEBfsk0k0HedO0nMXE2RFonr3qpGLgIq+BfzbM9u1UfX3c+g9O0vqVW sE9A== X-Gm-Message-State: ALyK8tJ3mTdbNQKTe5ORWJd9PRIDtzd0/ApXZJr4RQ/zKaqEvG0tIrQHsUpgjDndqpS/Z9PESJn8KrAymMiqAFve X-Received: by 10.107.173.66 with SMTP id w63mr144286ioe.110.1464820156695; Wed, 01 Jun 2016 15:29:16 -0700 (PDT) MIME-Version: 1.0 From: David Benjamin Date: Wed, 01 Jun 2016 22:29:06 +0000 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114467c219c3d205343f058c Archived-At: Subject: [TLS] Downgrade protection, fallbacks, and server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 22:29:20 -0000 --001a114467c219c3d205343f058c Content-Type: text/plain; charset=UTF-8 In case folks hoped we could bump the ClientHello version without those dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much exists. (Maybe we should just give up on ClientHello.version and use an extension? Extensions have rusted less.) I picked a large list of top sites and tried connecting to them. Just under 2% of them could handle a TLS 1.2 ClientHello, but not the same ClientHello with the version switched to 1.3 (no other changes, so I haven't tested a real 1.3 ClientHello). They're not unknown hosts either. I expect if you probe any top site list, you'll very quickly find some. Fortunately, the ServerHello.random trick fixes this. But it currently clobbers the old server timestamp which tlsdate[1] uses for clock synchronization. There really should be a less silly secure timestamping protocol, but, today, tlsdate has users. Any servers which expect to be a tlsdate target can't honor this MUST without tlsdate gone. (FALLBACK_SCSV works fine as well, but I gather people prefer the ServerHello.random one and would be unhappy having to implement both in clients with a fallback because not all servers do the latter.) I mentioned this before, but rather than clobbering the first 8 bytes, the last 8 bytes seems as reasonable and avoids this unnecessary complication to TLS 1.3 deployment. If folks agree now that the fallback's resurrection is more certain, I'm happy to put together a PR. David [1] https://github.com/ioerror/tlsdate --001a114467c219c3d205343f058c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In case folks hoped we could bump the ClientHello version = without those dreaded browser fallbacks, I have bad news. :-( 1.3 intoleran= ce very much exists. (Maybe we should just give up on ClientHello.version a= nd use an extension? Extensions have rusted less.)

I pic= ked a large list of top sites and tried connecting to them. Just under 2% o= f them could handle a TLS 1.2 ClientHello, but not the same ClientHello wit= h the version switched to 1.3 (no other changes, so I haven't tested a = real 1.3 ClientHello). They're not unknown hosts either. I expect if yo= u probe any top site list, you'll very quickly find some.
Fortunately, the ServerHello.random trick fixes this. But it cu= rrently clobbers the old server timestamp which tlsdate[1] uses for clock s= ynchronization. There really should be a less silly secure timestamping pro= tocol, but, today, tlsdate has users. Any servers which expect to be a tlsd= ate target can't honor this MUST without tlsdate gone.

(FALLBACK_SCSV works fine as well, but I gather people prefer the = ServerHello.random one and would be unhappy having to implement both in cli= ents with a fallback because not all servers do the latter.)

=
I mentioned this before, but rather than clobbering the first 8 = bytes, the last 8 bytes seems as reasonable and avoids this unnecessary com= plication to TLS 1.3 deployment.=C2=A0If fo= lks agree now that the fallback's resurrection is more certain, I'm= happy to put together a PR.

David

--001a114467c219c3d205343f058c-- From nobody Wed Jun 1 15:43:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23B612B040 for ; Wed, 1 Jun 2016 15:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIcDXL4tIy4t for ; Wed, 1 Jun 2016 15:43:48 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002: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 E515512B00F for ; Wed, 1 Jun 2016 15:43:47 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id h19so33328037ywc.0 for ; Wed, 01 Jun 2016 15:43:47 -0700 (PDT) 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; bh=c1fCYrBQ0785zOFkoDUTYveS/KlYFSAZzwpkRUpMI9Y=; b=BcPjzTzBVbsXwkaannNA4skStdRJT1DQ/pKZwlJooAETy8gk672DhLmz7gPiGIezjr JXaBX8ZNLTnsvimTFhst2lW1CKc2Vl1hzSc3hvfm/yOGiEADFXM3DJh4JdR8yq/QJvvy dV+vQi+4M0RSYiaQJzd2ahIsmOxTREkFUUumYjMboarKCNCHs2o0kQsxt/bobwK4LYtN 4PJitzSNpKzLQ4IFwtsRoA9v5AKLR48banqKhBQeqV4+TDVBoUnvinkL3bLzOUlwI7hy vpsJWL1qGgmMUp/J8Gp8RZ2F2vfZTMe6RbjHZ0xDJweIz1t0zF5bVw9ooSeqVcOpSPtd 3tjA== 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; bh=c1fCYrBQ0785zOFkoDUTYveS/KlYFSAZzwpkRUpMI9Y=; b=WfoTSDPETov9VHIQrkzA+hhdEaWiFcOW9DinlBJo+sqFvk9wCljKTwh8L0QtsXiWu4 nnNHl2vdhCRMtwTg21X0WFiISymwDjtJjSEdPzi24hWH+BVp7oG7Qg/kRJel5fGNnwaJ Fra6nMV1V4OpJQVK9gG2rzyk8PYyjjobvuDjIfYSLbda113ZpyjVpVVPk20O0j+jcizx CyZDYnYkjrkoPbgeDcffiGX7J8KFvpCqnPU3IdqKlQSiRTBoYAFc8Zg4Jc7ay+Sj3FZk SMi+7DLyYNUvUTZlvHJGcNyETMFffaZ/BamqaDOFxHc1xE0Awmo9StPQ/U5MoCCjEzZR SHoA== X-Gm-Message-State: ALyK8tIPHgz/UFqeLDhPrzPZbJAfvgli4Lfa98Pujo4H0iSbK4L+lFkrRG27nSKWWRfy7loenrcrYrM5RE7TJQ== X-Received: by 10.129.51.148 with SMTP id z142mr3846411ywz.322.1464821027214; Wed, 01 Jun 2016 15:43:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.230.76 with HTTP; Wed, 1 Jun 2016 15:43:07 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 1 Jun 2016 15:43:07 -0700 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a11422568fcc67905343f3824 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Downgrade protection, fallbacks, and server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 22:43:51 -0000 --001a11422568fcc67905343f3824 Content-Type: text/plain; charset=UTF-8 2% is actually pretty good, but I agree that we're going to need fallback. I'd be fine with moving the 8 bytes to the end, but I wonder if it would be better to instead have the *client* indicate its max version and the server check. That would have the advantage that it would leave more of the server random intact. -Ekr P.S. The FALLBACK_SCSV isn't a substitute because it isn't signed by the server. On Wed, Jun 1, 2016 at 3:29 PM, David Benjamin wrote: > In case folks hoped we could bump the ClientHello version without those > dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much > exists. (Maybe we should just give up on ClientHello.version and use an > extension? Extensions have rusted less.) > > I picked a large list of top sites and tried connecting to them. Just > under 2% of them could handle a TLS 1.2 ClientHello, but not the same > ClientHello with the version switched to 1.3 (no other changes, so I > haven't tested a real 1.3 ClientHello). They're not unknown hosts either. I > expect if you probe any top site list, you'll very quickly find some. > > Fortunately, the ServerHello.random trick fixes this. But it currently > clobbers the old server timestamp which tlsdate[1] uses for clock > synchronization. There really should be a less silly secure timestamping > protocol, but, today, tlsdate has users. Any servers which expect to be a > tlsdate target can't honor this MUST without tlsdate gone. > > (FALLBACK_SCSV works fine as well, but I gather people prefer the > ServerHello.random one and would be unhappy having to implement both in > clients with a fallback because not all servers do the latter.) > > I mentioned this before, but rather than clobbering the first 8 bytes, the > last 8 bytes seems as reasonable and avoids this unnecessary complication > to TLS 1.3 deployment. If folks agree now that the fallback's > resurrection is more certain, I'm happy to put together a PR. > > David > > [1] https://github.com/ioerror/tlsdate > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11422568fcc67905343f3824 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2% is actually pretty good, but I agree that we're goi= ng to need fallback.

I'd be fine with moving the 8 b= ytes to the end, but I wonder if it would be better to
instead ha= ve the *client* indicate its max version and the server check. That would
have the advantage that it would leave more of the server random i= ntact.

-Ekr

P.S. The = FALLBACK_SCSV isn't a substitute because it isn't signed by the ser= ver.


On Wed, Jun 1, 2016 at 3:29 PM, David Benjamin <= ;davidben@chromi= um.org> wrote:
In case folks hoped we could bump the ClientHello version without thos= e dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much= exists. (Maybe we should just give up on ClientHello.version and use an ex= tension? Extensions have rusted less.)

I picked a large = list of top sites and tried connecting to them. Just under 2% of them could= handle a TLS 1.2 ClientHello, but not the same ClientHello with the versio= n switched to 1.3 (no other changes, so I haven't tested a real 1.3 Cli= entHello). They're not unknown hosts either. I expect if you probe any = top site list, you'll very quickly find some.

= Fortunately, the ServerHello.random trick fixes this. But it currently clob= bers the old server timestamp which tlsdate[1] uses for clock synchronizati= on. There really should be a less silly secure timestamping protocol, but, = today, tlsdate has users. Any servers which expect to be a tlsdate target c= an't honor this MUST without tlsdate gone.

(FA= LLBACK_SCSV works fine as well, but I gather people prefer the ServerHello.= random one and would be unhappy having to implement both in clients with a = fallback because not all servers do the latter.)

I= mentioned this before, but rather than clobbering the first 8 bytes, the l= ast 8 bytes seems as reasonable and avoids this unnecessary complication to= TLS 1.3 deployment.=C2=A0If folks agree no= w that the fallback's resurrection is more certain, I'm happy to pu= t together a PR.

David

=

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


--001a11422568fcc67905343f3824-- From nobody Wed Jun 1 15:53:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C87112D573 for ; Wed, 1 Jun 2016 15:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYGseXhm63_3 for ; Wed, 1 Jun 2016 15:53:35 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 4C22F12D15A for ; Wed, 1 Jun 2016 15:53:35 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id i127so36802022ita.1 for ; Wed, 01 Jun 2016 15:53:35 -0700 (PDT) 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 :cc; bh=xZpw9nlR3NnSRqLTJHDj/gt37tcWWMBYBylT0l0441A=; b=MH5cLz9AyqPCXF0Wk4F2nv55DeJw7IdYYZJH8SobQLF+Ct27bezEevpR2dIVGIimqX LeICuXNhpruI1ImkN3HkDkBCeBWT6aEWunjtzuX38L53y49lyzSEENvIOAkIVtBY7/A0 Kka9uu3z8uMYsXXbWhhEz78njI7JdBXNgtNgg= 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:cc; bh=xZpw9nlR3NnSRqLTJHDj/gt37tcWWMBYBylT0l0441A=; b=mY7Cguq3MmhOnQBNRO9rw7tWOcOTvk0I2TERcHKsuL4rNDY/ZspCE9JUIbXgumySsh 51P3fwONN2lx6kr3XsFGniny2IPT+jXpc1cRBzO4WlEtgorIRnskhViQbkDHv7N6b+pJ B7fWO073zp7+ZZ7rsTib3B2xANePGYdVYheiyTwvYOkbUvZ9cqLOI7DRy0E4ObD5CptQ FNwKD1Rz0FTr/l4m0J9MNDVnHV69ECLkBM9yIWJY+FTRd/JJywQ7tJ0MuFA7st1wrNO4 LxXSOuniTt/S2lck28CY6BoC0h6SMASoxw9EJKWUr2Ow9awRWOuWC0/xQJcj//IerlTX 8mgQ== X-Gm-Message-State: ALyK8tLDzFxJ78B1b82e31BcruBjG8rqJdv/I6SuWDS7S+2ur/HuSdBGbaPK3YB+7MGVm797D5aml5zglQzGYIzo X-Received: by 10.36.230.129 with SMTP id e123mr441221ith.92.1464821614428; Wed, 01 Jun 2016 15:53:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 01 Jun 2016 22:53:24 +0000 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c006f64fd3c0e05343f5b81 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Downgrade protection, fallbacks, and server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 22:53:38 -0000 --94eb2c006f64fd3c0e05343f5b81 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 1, 2016 at 6:43 PM Eric Rescorla wrote: > 2% is actually pretty good, but I agree that we're going to need fallback. > > I'd be fine with moving the 8 bytes to the end, but I wonder if it would > be better to > instead have the *client* indicate its max version and the server check. > That would > have the advantage that it would leave more of the server random intact. > That sounds reasonable to me. I'd probably suggest still putting it at the end since there's no reason to risk things, but I'm not aware of anything that uses the client timestamp. (None of the clients I maintain send it.) > -Ekr > > P.S. The FALLBACK_SCSV isn't a substitute because it isn't signed by the > server. > Yeah, FALLBACK_SCSV only gives us TLS 1.0-1.2-level downgrade protection (otherwise the version fallback even loses that one). I only mean in terms of mitigating the additional damage done by the fallback, not replacing the entire mechanism. (Although, do we actually get the stronger protection if the client accepts plain RSA key exchange? I've never been very clear on that. Realistically, clients will be accepting plain RSA for a long while.) David > > On Wed, Jun 1, 2016 at 3:29 PM, David Benjamin > wrote: > >> In case folks hoped we could bump the ClientHello version without those >> dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much >> exists. (Maybe we should just give up on ClientHello.version and use an >> extension? Extensions have rusted less.) >> >> I picked a large list of top sites and tried connecting to them. Just >> under 2% of them could handle a TLS 1.2 ClientHello, but not the same >> ClientHello with the version switched to 1.3 (no other changes, so I >> haven't tested a real 1.3 ClientHello). They're not unknown hosts either. I >> expect if you probe any top site list, you'll very quickly find some. >> >> Fortunately, the ServerHello.random trick fixes this. But it currently >> clobbers the old server timestamp which tlsdate[1] uses for clock >> synchronization. There really should be a less silly secure timestamping >> protocol, but, today, tlsdate has users. Any servers which expect to be a >> tlsdate target can't honor this MUST without tlsdate gone. >> >> (FALLBACK_SCSV works fine as well, but I gather people prefer the >> ServerHello.random one and would be unhappy having to implement both in >> clients with a fallback because not all servers do the latter.) >> >> I mentioned this before, but rather than clobbering the first 8 bytes, >> the last 8 bytes seems as reasonable and avoids this unnecessary >> complication to TLS 1.3 deployment. If folks agree now that the >> fallback's resurrection is more certain, I'm happy to put together a PR. >> >> David >> >> [1] https://github.com/ioerror/tlsdate >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > --94eb2c006f64fd3c0e05343f5b81 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 1,= 2016 at 6:43 PM Eric Rescorla <ekr@rtfm= .com> wrote:
2% is actually pretty good, but I agree that we're going to need fall= back.

I'd be fine with moving the 8 bytes to the end= , but I wonder if it would be better to
instead have the *client*= indicate its max version and the server check. That would
have t= he advantage that it would leave more of the server random intact.

That sounds reasonable to me. I'd p= robably suggest still putting it at the end since there's no reason to = risk things, but I'm not aware of anything that uses the client timesta= mp. (None of the clients I maintain send it.)
=C2=A0
-Ekr

=
P.S. The FALLBACK_SCSV isn't a substitute because it isn't sig= ned by the server.

Yeah, FALLBACK_S= CSV only gives us TLS 1.0-1.2-level downgrade protection (otherwise the ver= sion fallback even loses that one). I only mean in terms of mitigating the = additional damage done by the fallback, not replacing the entire mechanism.=

(Although, do we actually get the stronger protection if the= client accepts plain RSA key exchange? I've never been very clear on t= hat. Realistically, clients will be accepting plain RSA for a long while.)<= /div>

David
=C2=A0

On Wed, Jun 1, 2016 = at 3:29 PM, David Benjamin <davidben@chromium.org> wrote= :
In case folks hoped we could bump the ClientHello version wit= hout those dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance = very much exists. (Maybe we should just give up on ClientHello.version and = use an extension? Extensions have rusted less.)

I picked= a large list of top sites and tried connecting to them. Just under 2% of t= hem could handle a TLS 1.2 ClientHello, but not the same ClientHello with t= he version switched to 1.3 (no other changes, so I haven't tested a rea= l 1.3 ClientHello). They're not unknown hosts either. I expect if you p= robe any top site list, you'll very quickly find some.

Fortunately, the ServerHello.random trick fixes this. But it curre= ntly clobbers the old server timestamp which tlsdate[1] uses for clock sync= hronization. There really should be a less silly secure timestamping protoc= ol, but, today, tlsdate has users. Any servers which expect to be a tlsdate= target can't honor this MUST without tlsdate gone.

(FALLBACK_SCSV works fine as well, but I gather people prefer the Ser= verHello.random one and would be unhappy having to implement both in client= s with a fallback because not all servers do the latter.)

I mentioned this before, but rather than clobbering the first 8 byt= es, the last 8 bytes seems as reasonable and avoids this unnecessary compli= cation to TLS 1.3 deployment.=C2=A0If folks= agree now that the fallback's resurrection is more certain, I'm ha= ppy to put together a PR.

David
<= br>

<= div class=3D"gmail_extra">
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--94eb2c006f64fd3c0e05343f5b81-- From nobody Wed Jun 1 15:54:17 2016 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 E09E112D512; Wed, 1 Jun 2016 15:54:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160601225413.16049.20878.idtracker@ietfa.amsl.com> Date: Wed, 01 Jun 2016 15:54:13 -0700 Archived-At: Cc: tls@ietf.org, tls-chairs@ietf.org Subject: [TLS] tls - Update to a Meeting Session Request for IETF 96 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 22:54:15 -0000 An update to a meeting session request has just been submitted by Sean Turner, a Chair of the tls working group. --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: spt Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: tokbind tcpinc stir saag rtcweb httpauth httpbis dane cfrg cose acme uta curdle perc Second Priority: sacm oauth Special Requests: Please also avoid the quic BOF. --------------------------------------------------------- From nobody Wed Jun 1 15:57:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE0012D0CE for ; Wed, 1 Jun 2016 15:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOE_BLuWPVF7 for ; Wed, 1 Jun 2016 15:57:22 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 0E12312D0C7 for ; Wed, 1 Jun 2016 15:57:22 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id c127so33450966ywb.1 for ; Wed, 01 Jun 2016 15:57:22 -0700 (PDT) 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; bh=Q/vHm898afUBJjzjwd5wwxb7Z4LLiw9gTglrr6yULT8=; b=A8QqYa0+eJl11Mys9qRd3YNAE694VjB/qDEB+WA7Keg+RYFWcHojvj83QTqDJMimRy txV/M7DWtDmIM0iBHD/vCudMA0/v+NhEJt87TQm5DaplLxrMcqFY9IDPCL+zm4oHj9MF gUE4ny2ezxA/pJXyxXZy3q5H31TYwHis3q5uQ6EzDAqHF48d6rOyJxYyLR3jA2eg11ec 4AVbAu0thCuF3GHYue2zJ8X+lQFOLeYsx+QprGsnybcatlzfKX0DoTflwy8qGE5o5W50 LgSRoterGosVRfSxXTvww8pFP3N5FfvezhkAWSukiObUupotLXce1UmTVnM7c8/7bzGS LyDQ== 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; bh=Q/vHm898afUBJjzjwd5wwxb7Z4LLiw9gTglrr6yULT8=; b=AbrM5FFNlp302bf2PBBdu10hv5Dlj4mfjeclo4BzbARwgjG/qWj4Whj75EwmuWnCZ7 NMs6uu5P3h1bqCHANNyKiJkLh3UcZwDpgQthLI2W48FQ3pTEbmtqZcXB83LOMvJoZ+Xe WvSuXllQxSte5ttny4tj6faf8/C5fcoEyGWzPm04XtDizhI6C1EsHdNEcvo6B1emd3pL x47VJ9D1ekmF1H+Xu8AejQodtcP38Gt6AThioTGuC+4lMHtlcmLwuEikaIuujWyYEyZw kKwhmYvJHqP0Y294TVpmpM4rGuXpeLIXeG4KpAY2vZ+OCuTRNDWL4jf62e2oZVzdGirF EUHg== X-Gm-Message-State: ALyK8tLVFLNpDQ9no4FQH1IIytxW9+3WQIC01vxMLpbxsJ9sQDkAqVIPlXxke3MherUyX4k2P8CosBgZ5WnaRw== X-Received: by 10.37.202.80 with SMTP id a77mr4018303ybg.74.1464821841314; Wed, 01 Jun 2016 15:57:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.230.76 with HTTP; Wed, 1 Jun 2016 15:56:41 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 1 Jun 2016 15:56:41 -0700 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=94eb2c05c59e82f50b05343f6949 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Downgrade protection, fallbacks, and server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 22:57:24 -0000 --94eb2c05c59e82f50b05343f6949 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 1, 2016 at 3:53 PM, David Benjamin wrote: > On Wed, Jun 1, 2016 at 6:43 PM Eric Rescorla wrote: > >> 2% is actually pretty good, but I agree that we're going to need fallback. >> >> I'd be fine with moving the 8 bytes to the end, but I wonder if it would >> be better to >> instead have the *client* indicate its max version and the server check. >> That would >> have the advantage that it would leave more of the server random intact. >> > > That sounds reasonable to me. I'd probably suggest still putting it at the > end since there's no reason to risk things, but I'm not aware of anything > that uses the client timestamp. (None of the clients I maintain send it.) > Putting it at the end of the client gives the client options, so that would be fine. > >> -Ekr >> >> P.S. The FALLBACK_SCSV isn't a substitute because it isn't signed by the >> server. >> > > Yeah, FALLBACK_SCSV only gives us TLS 1.0-1.2-level downgrade protection > (otherwise the version fallback even loses that one). I only mean in terms > of mitigating the additional damage done by the fallback, not replacing the > entire mechanism. > > (Although, do we actually get the stronger protection if the client > accepts plain RSA key exchange? I've never been very clear on that. > Realistically, clients will be accepting plain RSA for a long while.) > Yes, that's correct. I don't believe we have a good plan for plain RSA. -Ekr > David > > >> >> On Wed, Jun 1, 2016 at 3:29 PM, David Benjamin >> wrote: >> >>> In case folks hoped we could bump the ClientHello version without those >>> dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much >>> exists. (Maybe we should just give up on ClientHello.version and use an >>> extension? Extensions have rusted less.) >>> >>> I picked a large list of top sites and tried connecting to them. Just >>> under 2% of them could handle a TLS 1.2 ClientHello, but not the same >>> ClientHello with the version switched to 1.3 (no other changes, so I >>> haven't tested a real 1.3 ClientHello). They're not unknown hosts either. I >>> expect if you probe any top site list, you'll very quickly find some. >>> >>> Fortunately, the ServerHello.random trick fixes this. But it currently >>> clobbers the old server timestamp which tlsdate[1] uses for clock >>> synchronization. There really should be a less silly secure timestamping >>> protocol, but, today, tlsdate has users. Any servers which expect to be a >>> tlsdate target can't honor this MUST without tlsdate gone. >>> >>> (FALLBACK_SCSV works fine as well, but I gather people prefer the >>> ServerHello.random one and would be unhappy having to implement both in >>> clients with a fallback because not all servers do the latter.) >>> >>> I mentioned this before, but rather than clobbering the first 8 bytes, >>> the last 8 bytes seems as reasonable and avoids this unnecessary >>> complication to TLS 1.3 deployment. If folks agree now that the >>> fallback's resurrection is more certain, I'm happy to put together a PR. >>> >>> David >>> >>> [1] https://github.com/ioerror/tlsdate >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> --94eb2c05c59e82f50b05343f6949 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 1, 2016 at 3:53 PM, David Benjamin <davidben@chromium.= org> wrote:
On Wed, Jun = 1, 2016 at 6:43 PM Eric Rescorla <ekr@rtfm.com> wrote:
2% is actually pretty good, but I agree that we'r= e going to need fallback.

I'd be fine with moving th= e 8 bytes to the end, but I wonder if it would be better to
inste= ad have the *client* indicate its max version and the server check. That wo= uld
have the advantage that it would leave more of the server ran= dom intact.

That sounds = reasonable to me. I'd probably suggest still putting it at the end sinc= e there's no reason to risk things, but I'm not aware of anything t= hat uses the client timestamp. (None of the clients I maintain send it.)

Putting it at the end of th= e client gives the client options, so that would be fine.


=C2=A0
-Ekr

P.S. The FA= LLBACK_SCSV isn't a substitute because it isn't signed by the serve= r.

=
Yeah, FALLBACK_SCSV only = gives us TLS 1.0-1.2-level downgrade protection (otherwise the version fall= back even loses that one). I only mean in terms of mitigating the additiona= l damage done by the fallback, not replacing the entire mechanism.

(Although, do we actually get the stronger protection if the client a= ccepts plain RSA key exchange? I've never been very clear on that. Real= istically, clients will be accepting plain RSA for a long while.)

Yes, that's correct. I don'= ;t believe we have a good plan for plain RSA.

-Ekr=

David
=C2=A0

O= n Wed, Jun 1, 2016 at 3:29 PM, David Benjamin <davidben@chromium.org> wrote:
In case folks hoped we could bump the Clie= ntHello version without those dreaded browser fallbacks, I have bad news. := -( 1.3 intolerance very much exists. (Maybe we should just give up on Clien= tHello.version and use an extension? Extensions have rusted less.)

=
I picked a large list of top sites and tried connecting to them.= Just under 2% of them could handle a TLS 1.2 ClientHello, but not the same= ClientHello with the version switched to 1.3 (no other changes, so I haven= 't tested a real 1.3 ClientHello). They're not unknown hosts either= . I expect if you probe any top site list, you'll very quickly find som= e.

Fortunately, the ServerHello.random trick fixes= this. But it currently clobbers the old server timestamp which tlsdate[1] = uses for clock synchronization. There really should be a less silly secure = timestamping protocol, but, today, tlsdate has users. Any servers which exp= ect to be a tlsdate target can't honor this MUST without tlsdate gone.<= /div>

(FALLBACK_SCSV works fine as well, but I gather pe= ople prefer the ServerHello.random one and would be unhappy having to imple= ment both in clients with a fallback because not all servers do the latter.= )

I mentioned this before, but rather than clobber= ing the first 8 bytes, the last 8 bytes seems as reasonable and avoids this= unnecessary complication to TLS 1.3 deployment.=C2=A0If folks agree now that the fallback's resurrection is more = certain, I'm happy to put together a PR.

David
<= div class=3D"gmail_extra">
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



--94eb2c05c59e82f50b05343f6949-- From nobody Wed Jun 1 18:42:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA44812D57A for ; Wed, 1 Jun 2016 18:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoGNpcsmpgGM for ; Wed, 1 Jun 2016 18:42:02 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d: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 16F6E12D57F for ; Wed, 1 Jun 2016 18:42:01 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id q32so117245791qgq.3 for ; Wed, 01 Jun 2016 18:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=v63ZAXobusV7AhVlsa4fFgvqOBMY/Z55Y4enIh9XMbs=; b=vLqeL+XzOualJCo9PBC2Ml5uRW/obEzebjZ9JflMFhDZiAJJng+1m9MAR9qVR09W2G XDqkFqMYM+pQMG64v8CyqSDmSbTBk7GKrDJHpFCyYFHSAokokCFtAF01GrcUYu6rExvj knz3hS2ywImsK3XbwxUz2qEdSCPM8N/rKPaP2FyvkHtCOVvbD629eXFlqbCQAV2wKqse nUFVQ2/f4mqzun7afsv3GV0IuYo/RLZgVkaMp/T/U/9TMgWLkqwME/Gd2tEJsDlp8GD4 /UhVF7sUd03U8N69qVtLFMde7DTzEorga8jWnNMVdJ4gllvD3SUcKgL+sW7ZW97WSobe 3scg== 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; bh=v63ZAXobusV7AhVlsa4fFgvqOBMY/Z55Y4enIh9XMbs=; b=T7kDpag6iW35Cu6LZIg+f+7kiPl2Mp2ZyBgZ5C9v/5pVcviunsjpY7ji9/EgsvT5dr DbDxgpVULfPn+Nxdmkdi8172+UrMWldyWGSJ8b69PLuy0ezLBmfCGTd2m1sZjTUeMYls OvWml+rhVOw/KrW5dqJcvjnAboYviTegy1JlVRGRmgXw2QV3JNUSCL9JR7rbycLMvfia S7n3v7PaSoaHWCOixtZNoEYHc6CalT31vtoThxAGbuKlJYpczARoWCXdluoMnai3kCM+ wJg23W3QzHduX+u3aq/1Y8s0O7db537EuRs4ptOINIcW0s194rcZ+3tFCxYQgDsLzBgD sPbA== X-Gm-Message-State: ALyK8tL9h5aud0kcwAmGD1Njk0SulEET0mnfP1I7fPyTao2B2JL9JPXNrtrAuSQHyQWFSCFraCZO1/eNLKPClw== MIME-Version: 1.0 X-Received: by 10.140.253.85 with SMTP id y82mr37797846qhc.94.1464831720258; Wed, 01 Jun 2016 18:42:00 -0700 (PDT) Received: by 10.140.104.110 with HTTP; Wed, 1 Jun 2016 18:42:00 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Jun 2016 11:42:00 +1000 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Downgrade protection, fallbacks, and server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2016 01:42:04 -0000 On 2 June 2016 at 08:56, Eric Rescorla wrote: >> (Although, do we actually get the stronger protection if the client >> accepts plain RSA key exchange? I've never been very clear on that. >> Realistically, clients will be accepting plain RSA for a long while.) > > > Yes, that's correct. I don't believe we have a good plan for plain RSA. The best plan involves lots and lots of fire. From nobody Thu Jun 2 00:31:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E8912D67E for ; Thu, 2 Jun 2016 00:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.348 X-Spam-Level: X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pyvTsBKETlv for ; Thu, 2 Jun 2016 00:31:34 -0700 (PDT) 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 A4EBC12D67A for ; Thu, 2 Jun 2016 00:31:34 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E7046709C2; Thu, 2 Jun 2016 07:31:33 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.110]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u527VVZH019928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Jun 2016 03:31:32 -0400 Message-ID: <1464852691.5804.1.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla , David Benjamin Date: Thu, 02 Jun 2016 09:31:31 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 02 Jun 2016 07:31:34 +0000 (UTC) Archived-At: Cc: "tls@ietf.org" Subject: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2016 07:31:36 -0000 On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote: > 2% is actually pretty good, but I agree that we're going to need > fallback. Please not. Lets let these fallbacks die. Not every client is a browser. TLS 1.3 must be a protocol which doesn't require hacks to operate. CBC was removed, lets do the same for insecure fallbacks. regards, Nikos From nobody Thu Jun 2 01:39:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5574D12D138 for ; Thu, 2 Jun 2016 01:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbAv8kFylF0X for ; Thu, 2 Jun 2016 01:39:25 -0700 (PDT) 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 9D2EA12D12F for ; Thu, 2 Jun 2016 01:39:25 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id a20so57633099wma.1 for ; Thu, 02 Jun 2016 01:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2rwKk5GJLp2gyXLtSvsNtehRVrEvPtxlDciNocy53kQ=; b=CZIJ/zLQohl5uZrdn39o+i43aGhrEQHB1AZUSszXOu59HcIaA2iedyiTLAa8FKnh9X 3KVq6DHblZlGRwUfplGL3YnBNnv1g4R8ZufhdWhMbyk4OSQd2Frx4nrH2i9w/x9CH5U4 eQcdovVWR0Bxm6PZ2Lcs5jqqNPdpUM8rmuwbCqOMuPPmBCDF6G1Ks/VeXV82oQQsgqIn V7bUTqdt0IP/RmuRv8QpzZ6F0J//I7vYo9qrrkic9ye7hRL00mIlZL8goA+U4q+AzoF7 FbRMpY3EzFKAVYvk7C1CRXQoYmAmgl2pD+eU0WBISREn5K9w5wZbJcuGKxhft/ClBYqD OKPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2rwKk5GJLp2gyXLtSvsNtehRVrEvPtxlDciNocy53kQ=; b=RlyQbPwWQnhJO84F62rlDiqop2svdIpC4rK+UzagMYnijyF25cYMuCZpb0mw5lgeyz XvYO1os/BL8xi+YEZsqMWeYI0b/NN4lj5puJYXu2A9Egw5YrC2iz3IeJ04Xew2DH0l5v Svzp3UVa2aZ3zTQZYgb9jIDgS+kxfRQTAiBmpllHIdp3kLbwVe9Toy9Q4oWhIjKEf/w9 N+8ou1xODIkgGBu/CK98H/vv5HUPYAJmxmeeRAegZY20/3axIkbESJI7Q1FHxmoFOYnc WYkc6yHjamMB7lXQrdZaxysakPqigawtb82OjJ9IPVp+stp3x9W/BHID9OKJzZsRWRUK HHyA== X-Gm-Message-State: ALyK8tLElZYwx262XCWBjJjEv713kyTaNGiR+goGKwC4GKXxtlK5vsk0FYQzbTCf3vKjlA== X-Received: by 10.28.53.135 with SMTP id c129mr6608634wma.16.1464856764041; Thu, 02 Jun 2016 01:39:24 -0700 (PDT) Received: from [172.24.251.142] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id d7sm39399794wmd.11.2016.06.02.01.39.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Jun 2016 01:39:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <1464852691.5804.1.camel@redhat.com> Date: Thu, 2 Jun 2016 11:39:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1464852691.5804.1.camel@redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2016 08:39:27 -0000 > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos = wrote: >=20 > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote: >> 2% is actually pretty good, but I agree that we're going to need >> fallback. >=20 > Please not. Lets let these fallbacks die. Not every client is a > browser. TLS 1.3 must be a protocol which doesn't require hacks to > operate. CBC was removed, lets do the same for insecure fallbacks. =20 Not every client is a browser, but some are. So what does the browser do = when a server resets the connection after seeing the ClientHello? Blank screen with a failure message?= From nobody Thu Jun 2 03:40:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF96512D132 for ; Thu, 2 Jun 2016 03:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.348 X-Spam-Level: X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7Wrh8QFzB6D for ; Thu, 2 Jun 2016 03:39:59 -0700 (PDT) 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 5E79412D0BE for ; Thu, 2 Jun 2016 03:39:59 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 152B0C00DDE7; Thu, 2 Jun 2016 10:39:59 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-138.brq.redhat.com [10.34.0.138]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u52Advb9030862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2016 06:39:58 -0400 From: Hubert Kario To: tls@ietf.org Date: Thu, 02 Jun 2016 12:39:57 +0200 Message-ID: <6238043.DCePXUsCVt@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.10-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2003030.C26EvmxeT8"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 02 Jun 2016 10:39:59 +0000 (UTC) Archived-At: Subject: Re: [TLS] Downgrade protection, fallbacks, and server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2016 10:40:01 -0000 --nextPart2003030.C26EvmxeT8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 01 June 2016 22:29:06 David Benjamin wrote: > In case folks hoped we could bump the ClientHello version without > those dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance= > very much exists. (Maybe we should just give up on > ClientHello.version and use an extension? Extensions have rusted > less.) >=20 > I picked a large list of top sites and tried connecting to them. Just= > under 2% of them could handle a TLS 1.2 ClientHello, but not the same= > ClientHello with the version switched to 1.3 (no other changes, so I > haven't tested a real 1.3 ClientHello). They're not unknown hosts > either. I expect if you probe any top site list, you'll very quickly > find some. there are also servers which choke on large extensions (say 4096 bit DH= =20 client key share with 384 bit ECDH key share), so avoiding the bump in=20= version number won't solve all the problems either... Speaking of version number, does the text say that a server _MUST_=20 accept any version higher than the one that is specified in the RFC, bu= t=20 reply with 0x03,0x04 in case it doesn't support any future version of=20= the protocol? It would be nice to have some kind of stick for the broke= n=20 implementations... =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 --nextPart2003030.C26EvmxeT8 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 iQIcBAABCgAGBQJXUAz9AAoJEJKo0bgB0vX1o7YQAIfyUcjY7UU50I3CXEWEXpYp MxfQEKkb3h8az2tARYAW6vVKakC6fO5kWATd5m+6l4RKnA0gZck6Ng/7D510YRt4 k6dWcCdpGkP0LdassYRsk9uPj2ODFXqs+0rSyllZylL1URTcXIAGprQETbH6vJSs zniyryVdCYNiAPUxRdcX3oXAtPBLcRFHuQeXWLwc8hNhn7xvUHst01tjaGzoq1LB wryRXpUzwlKXsn9q4Pv80DupzjpR7P97KcNhudhBEqbTJT3maEdSWXS/OAcMGEUc 7K4+ojhlfduKqNKUgyGP3KqjypcRgAWscdVXXeYTJ3zQCqD0zVZmmAZjcitoAYoK wu5ylFVi8kh+Gmoy6tkdmt6kZR0/ZQFBsOu/wNAs6v3HzLjEDyHbIa+xSTUASl1S rQvIYYoQc5VZM/LmC5vmdDa3IWoBdRjJeyEFjODB3D5IOv54/MW6Bcjf2JYWxHFO yAWNkNQu9Qyq/zIkM6engUbOeFUmM/P+0Ch677sYVXIynfOXcCHOXNXSTAh2ey49 BoDHeC+bN9o5I870i5H6wMZ/7K2tgip/TlTJB5XSQMvniL4lWb4Tl/jojP0m0v59 8JPAgc7BtNl+ME/DNt9L1VA8L807Yv4dV4MeDNs8GdbnMsdnPKGDW57zyHLZbdyB PKHd4rOtpd5EsfEoHXI3 =rKS+ -----END PGP SIGNATURE----- --nextPart2003030.C26EvmxeT8-- From nobody Thu Jun 2 03:43:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4A512D6A8 for ; Thu, 2 Jun 2016 03:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.348 X-Spam-Level: X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxehJFDufM_h for ; Thu, 2 Jun 2016 03:43:50 -0700 (PDT) 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 515E812D681 for ; Thu, 2 Jun 2016 03:43:50 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 162AD7F084; Thu, 2 Jun 2016 10:43:50 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-138.brq.redhat.com [10.34.0.138]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u52AhmJH015925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2016 06:43:49 -0400 From: Hubert Kario To: tls@ietf.org Date: Thu, 02 Jun 2016 12:43:48 +0200 Message-ID: <3713097.ExV049UdFl@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.10-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: References: <1464852691.5804.1.camel@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2732446.AWuzS6Lrkc"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 02 Jun 2016 10:43:50 +0000 (UTC) Archived-At: Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2016 10:43:52 -0000 --nextPart2732446.AWuzS6Lrkc Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 02 June 2016 11:39:20 Yoav Nir wrote: > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos > > wrote:>=20 > > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote: > >> 2% is actually pretty good, but I agree that we're going to need > >> fallback. > >=20 > > Please not. Lets let these fallbacks die. Not every client is a > > browser. TLS 1.3 must be a protocol which doesn't require hacks to > > operate. CBC was removed, lets do the same for insecure fallbacks. >=20 > Not every client is a browser, but some are. So what does the browser= > do when a server resets the connection after seeing the ClientHello? >=20 > Blank screen with a failure message? fallback to check if the connection failure is caused by TLSv1.3, and i= f=20 it is, display error message and put the blame squarely on the server =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 --nextPart2732446.AWuzS6Lrkc 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 iQIcBAABCgAGBQJXUA3kAAoJEJKo0bgB0vX1iO0P/R4o40yLIiUZ5fPpaFPeWKr7 CY9tmfn1w12RLQx58aXo9vg2ZVet0uwkgfvJgcRu7OZn1xy3+L1zxUxBeWagS3TZ c2lLSa1vByq2qppiJbgVHwHqYOy3MZQMmDyA9hwQ6CwLB3gpa2WboIBVGY4hyuJR 7JKqoarRU3z9GyfDzKv90R/v/s5Iu+RcHXgHi1W5Fj8E6W+Erhp6wdNwwW+hdyQI delhthCpk7fMTzCn4uzKStpjKacT3LfA2mJ8X5xrOpyXxz7fos1cAzr9uBVmOgQn xUFfMB4MikV+iIgPfL5jTFpbC/iSjFQHySSt8eqE2v6TiiYWc48xQvmaxUk+61Al SjkCIn33e7uprFX3uobsT5WxObucAs7OT/ua455/PdxWfo2ZX3PNZJe0rB1etd2g u/BzUkak8WFtgjt2uACwDzoMMuFl9gXkSPHL3+5o+emr/ZysceAjSL02GNYAD63v l0U/OoHNMlv/JJ9GQ6EhX7LFzGkgUzDu62gou9BxPKeWhF8vtjePhElG5QJUJVXj Qr9oO8igUaIOlES7ZtMyMDvbuqkzxtBGbltYXs+jyJJNouw1SlwiiGkxiTvxKHbX Xyh+yOpeVfBpiP/60VledEZbz8GDgjtN+sAPOh1cTWHDPNa54KOEMkS3ZfkjOUjz fiHbiB6FWJWSCA28xAn8 =yHqd -----END PGP SIGNATURE----- --nextPart2732446.AWuzS6Lrkc-- From nobody Thu Jun 2 07:50:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C8F12D0F1 for ; Thu, 2 Jun 2016 07:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIB6XcZBfZEQ for ; Thu, 2 Jun 2016 07:50:03 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 07E2C12D0ED for ; Thu, 2 Jun 2016 07:50:03 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id e62so127584128ita.1 for ; Thu, 02 Jun 2016 07:50:02 -0700 (PDT) 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; bh=LaJEhWgJf5wc2tXz7bVGm29QBUxxA4fOXRzwd2vn5Ow=; b=U6mD8JMnyY+s/D+m+EznKmre68wGJK67Er1Y0o7bpmSo6K3Baj4EJVPVy+1XUPREGL RenMJxd3CUHI19FjRnyJtuG6oJfEde8tOWboRN8VPyh54oruV1xCZeh2GLad0i8worsY l1R6lgKY2Wl38akbNlZANqzXpkcRMK3Zkn2CQ= 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; bh=LaJEhWgJf5wc2tXz7bVGm29QBUxxA4fOXRzwd2vn5Ow=; b=D1qyLpiRYayzVfwOQ3ppbRaeAySFngme0/hBzdUx5qzXdpComxwLmB8KQy+HAqoalI VNd+aNey0eTwwJdooiyY0KSw6Ad3rStNXcFdfxqr9mkRABMHLmyBhcuBVHGMFmFoCMfP MLcvXFVvLBQD5NMxRF5QA5HetZTt3RsIi9lTsAKWLCDDVLP4aovyTd7WEJO4gD8FQ1BM vPdyMpTI0qmUsq7puDQHMla5MClB7hJLxsiIXjfMcfvUllC13B5Bb8z+3qM48h67Rr8m 7ATy6tztR5VxtYO4WWl/ncrHbJ837V6MOvzaJsFFi1ZyyFZLh9ad9nsSiN0biuQrPV/g mdvg== X-Gm-Message-State: ALyK8tI0O5cFeceGIpKLeUWaxk7y/PwYUVhLvgSW8kB2+4p4HS40qX1JkfSLZO2iuJvL82ll6f4VGGY3e74nbxRT X-Received: by 10.36.61.202 with SMTP id n193mr4168649itn.92.1464879002124; Thu, 02 Jun 2016 07:50:02 -0700 (PDT) MIME-Version: 1.0 References: <6238043.DCePXUsCVt@pintsize.usersys.redhat.com> In-Reply-To: <6238043.DCePXUsCVt@pintsize.usersys.redhat.com> From: David Benjamin Date: Thu, 02 Jun 2016 14:49:52 +0000 Message-ID: To: Hubert Kario , tls@ietf.org Content-Type: multipart/alternative; boundary=001a1145bb4690088905344cb838 Archived-At: Subject: Re: [TLS] Downgrade protection, fallbacks, and server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2016 14:50:05 -0000 --001a1145bb4690088905344cb838 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 2, 2016 at 6:40 AM Hubert Kario wrote: > On Wednesday 01 June 2016 22:29:06 David Benjamin wrote: > > In case folks hoped we could bump the ClientHello version without > > those dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance > > very much exists. (Maybe we should just give up on > > ClientHello.version and use an extension? Extensions have rusted > > less.) > > > > I picked a large list of top sites and tried connecting to them. Just > > under 2% of them could handle a TLS 1.2 ClientHello, but not the same > > ClientHello with the version switched to 1.3 (no other changes, so I > > haven't tested a real 1.3 ClientHello). They're not unknown hosts > > either. I expect if you probe any top site list, you'll very quickly > > find some. > > there are also servers which choke on large extensions (say 4096 bit DH > client key share with 384 bit ECDH key share), so avoiding the bump in > version number won't solve all the problems either... > TLS 1.3 doesn't require clients offer a KeyShare for all groups in the first ClientHello. It costs a HelloRetryRequest and another round-trip, but I think that's fine. Clients can limit FFDHE in the initial ClientHello to servers they've spoken to before or something. For unknown servers, if you only predict a couple of EC groups, it shouldn't blow it up too badly, but of course we'll just have to see. (Or clients can just not bother with FFDHE to begin with. I don't see the point and am not very interested in implementing it at all.) > Speaking of version number, does the text say that a server _MUST_ > accept any version higher than the one that is specified in the RFC, but > reply with 0x03,0x04 in case it doesn't support any future version of > the protocol? It would be nice to have some kind of stick for the broken > implementations... > I'm not sure I follow. The specification certainly spells out how version negotiation is supposed to work. That hasn't stopped servers from getting it wrong. Fundamentally this is the sort of thing where bugs don't get noticed until we make a new TLS version, and we don't do that often enough to keep rust from gathering. David --001a1145bb4690088905344cb838 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 2,= 2016 at 6:40 AM Hubert Kario <hkario@redhat.com> wrote:
On Wednesday 01 June 2016 22:29:06 David Benjamin wrote:
> In case folks hoped we could bump the ClientHello version without
> those dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance<= br> > very much exists. (Maybe we should just give up on
> ClientHello.version and use an extension? Extensions have rusted
> less.)
>
> I picked a large list of top sites and tried connecting to them. Just<= br> > under 2% of them could handle a TLS 1.2 ClientHello, but not the same<= br> > ClientHello with the version switched to 1.3 (no other changes, so I > haven't tested a real 1.3 ClientHello). They're not unknown ho= sts
> either. I expect if you probe any top site list, you'll very quick= ly
> find some.

there are also servers which choke on large extensions (say 4096 bit DH
client key share with 384 bit ECDH key share), so avoiding the bump in
version number won't solve all the problems either...
<= div>
TLS 1.= 3 doesn't require clients offer a KeyShare for all groups in the first = ClientHello. It costs a HelloRetryRequest and another round-trip, but I thi= nk that's fine.=C2=A0Clients can limit = FFDHE in the initial ClientHello to servers they've spoken to before or= something. For unknown servers, if you only predict a couple of EC groups,= it shouldn't blow it up too badly, but of course we'll just have t= o see.

(Or clients can just not bother with= FFDHE to begin with. I don't see the point and am not very interested = in implementing it at all.)
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Speaking of version number, does the text say that a server _MUST_
accept any version higher than the one that is specified in the RFC, but reply with 0x03,0x04 in case it doesn't support any future version of the protocol? It would be nice to have some kind of stick for the broken implementations...

I'm not sure I follow. The specific= ation certainly spells out how version negotiation is supposed to work. Tha= t hasn't stopped servers from getting it wrong. Fundamentally this is t= he sort of thing where bugs don't get noticed until we make a new TLS v= ersion, and we don't do that often enough to keep rust from gathering.<= /div>

David
--001a1145bb4690088905344cb838-- From nobody Thu Jun 2 07:59:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1CD12D1CD for ; Thu, 2 Jun 2016 07:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dyP_2Efhtjh for ; Thu, 2 Jun 2016 07:59:47 -0700 (PDT) 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 5A62E12D1B2 for ; Thu, 2 Jun 2016 07:59:47 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 3D415284B14 for ; Thu, 2 Jun 2016 14:59:46 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 2 Jun 2016 10:59:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6238043.DCePXUsCVt@pintsize.usersys.redhat.com> To: tls@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Downgrade protection, fallbacks, and server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jun 2016 14:59:49 -0000 > On Jun 2, 2016, at 10:49 AM, David Benjamin = wrote: >=20 > I'm not sure I follow. The specification certainly spells out how = version negotiation is supposed to work. That hasn't stopped servers = from getting it wrong. Fundamentally this is the sort of thing where = bugs don't get noticed until we make a new TLS version, and we don't do = that often enough to keep rust from gathering. A better way to keep rust from gathering is to not instutionalize = fallback, force the broken sites to deal with the issue. While 2% is noticeable, = you can probably drive 1.3 version intolerance out of the ecosystem = relatively quickly if Chrome implements fallback for a limited time (say 6 months = after TLS 1.3 RFC is done) and with a diminishing probability (60% first = month, 10% less each month thereafter), season to taste. --=20 Viktor. From nobody Thu Jun 2 08:08:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A9712D734 for ; Thu, 2 Jun 2016 08:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPyiEkm3-NM7 for ; Thu, 2 Jun 2016 08:08:13 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 F08C612D735 for ; Thu, 2 Jun 2016 08:08:03 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id e62so128154586ita.1 for ; Thu, 02 Jun 2016 08:08:03 -0700 (PDT) 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; bh=9aeiMbo9hdx4bjX80xblT7uGIgoTxWSN8NQ0afcM9L0=; b=Z2dqvlqX9UEqItDweXtvedZWbae5LCfg6rDfUdiPSmod1NmQLln2avTLcHJ7AM43gh xrAl63c50Sf5aJPeoSGP6XTLy1dgRUEJX7/1PXxjFg0Lj+ijFO+hfMTCKh+c1tXevnrJ vrP8b4h5ZfoUb0YkdusdYa/gllZxyn2ne0V5o= 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; bh=9aeiMbo9hdx4bjX80xblT7uGIgoTxWSN8NQ0afcM9L0=; b=RydWuRHpZjrerQzxnSH4wMA62gQ3PTPk8vlVRuhb0USmkSkZrow62Gm8WY+4MSQQFF 8fyy4ALPeNSBcfkT7Rq7yhkwWS9kAd6NXh7of3LDQxv7zZv68zpSV3pzK3XBhcRvhhi0 h767iz6zO9IrWtutYvL36BJWA2bj1YwAxmIYy3XaboCJUmBEYj8ww1+e8MaVirgm+Psb 0kiba0UX0qipPsexfQnlvGaKyka0Nyzu358V/QcMgIf2bgi8NIavJAdg4j68Hs1b5m/k bQY5sOmv8Fr3H9TSkK7P9vnfZQs57+QqYcHXDrpYNFnZuf2rAUCpEQN0bVBdTZnpOFdT 63MA== X-Gm-Message-State: ALyK8tLfZ8STSEaoS/wX5Zb7eCy6urVBLQ9Ug0VeGyv6QjxzIq8CCp4YNyKP61ePUhBFvdZUm4DXZ6pofum0Vqlv X-Received: by 10.36.101.74 with SMTP id u71mr282078itb.92.1464880083211; Thu, 02 Jun 2016 08:08:03 -0700 (PDT) MIME-Version: 1.0 References: <1464852691.5804.1.camel@redhat.com> <3713097.ExV049UdFl@pintsize.usersys.redhat.com> In-Reply-To: <3713097.ExV049UdFl@pintsize.usersys.redhat.com> From: David Benjamin Date: Thu, 02 Jun 2016 15:07:53 +0000 Message-ID: To: Hubert Kario , tls@ietf.org Content-Type: multipart/alternative; boundary=001a1145bcf2fff0ae05344cf881 Archived-At: Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2016 15:08:18 -0000 --001a1145bcf2fff0ae05344cf881 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario wrote: > On Thursday 02 June 2016 11:39:20 Yoav Nir wrote: > > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos > > > wrote:> > > > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote: > > >> 2% is actually pretty good, but I agree that we're going to need > > >> fallback. > > > > > > Please not. Lets let these fallbacks die. Not every client is a > > > browser. TLS 1.3 must be a protocol which doesn't require hacks to > > > operate. CBC was removed, lets do the same for insecure fallbacks. > > > > Not every client is a browser, but some are. So what does the browser > > do when a server resets the connection after seeing the ClientHello? > > > > Blank screen with a failure message? > > fallback to check if the connection failure is caused by TLSv1.3, and if > it is, display error message and put the blame squarely on the server > We browser folk hate these fallbacks just enough as much as you do, if not more. I personally spent quite a lot of time and effort getting rid of it in Chrome (and I'm happy to say, as of Chrome 50, I seem to have succeeded). I'm sure my counterparts at Mozilla went through similar pains. But reality is what it is. The Law of the Internet is the last thing that changed is blamed. We have a limited "budget" we can spend breaking things (otherwise I'd have removed almost everything by now!) and there is no chance I can break all the hosts I found. I have been reaching out to figure out the broken vendors, but this is a slow process. It will not be flushed this out anytime soon. With TLS 1.3 as it stands, I think a browser fallback in the short to medium term is a certainty. (If your clients don't need it, then by all means don't add one! I envy you.) David --001a1145bcf2fff0ae05344cf881 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 2,= 2016 at 6:43 AM Hubert Kario <hkar= io@redhat.com> wrote:
On Thu= rsday 02 June 2016 11:39:20 Yoav Nir wrote:
> > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos
> > <nmav@red= hat.com> wrote:>
> > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote:
> >> 2% is actually pretty good, but I agree that we're going = to need
> >> fallback.
> >
> > Please not. Lets let these fallbacks die. Not every client is a > > browser. TLS 1.3 must be a protocol which doesn't require hac= ks to
> > operate. CBC was removed, lets do the same for insecure fallbacks= .
>
> Not every client is a browser, but some are. So what does the browser<= br> > do when a server resets the connection after seeing the ClientHello? >
> Blank screen with a failure message?

fallback to check if the connection failure is caused by TLSv1.3, and if it is, display error message and put the blame squarely on the server

We browser folk hate these fallbacks just en= ough as much as you do, if not more. I personally spent quite a lot of time= and effort getting rid of it in Chrome (and I'm happy to say, as of Ch= rome 50, I seem to have succeeded). I'm sure my counterparts at Mozilla= went through similar pains.

But reality is what i= t is. The Law of the Internet is the last thing that changed is blamed. We = have a limited "budget" we can spend breaking things (otherwise I= 'd have removed almost everything by now!) and there is no chance I can= break all the hosts I found.

I have been reaching= out to figure out the broken vendors, but this is a slow process. It will = not be flushed this out anytime soon. With TLS 1.3 as it stands, I think a = browser fallback in the short to medium term is a certainty. (If your clien= ts don't need it, then by all means don't add one! I envy you.)

David
--001a1145bcf2fff0ae05344cf881-- From nobody Thu Jun 2 08:17:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFBB12D766 for ; Thu, 2 Jun 2016 08:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrnhjtOwmAFJ for ; Thu, 2 Jun 2016 08:17:17 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001: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 80FDD12D765 for ; Thu, 2 Jun 2016 08:17:07 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id k19so35553802ioi.3 for ; Thu, 02 Jun 2016 08:17:07 -0700 (PDT) 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; bh=P40dklr8M2mcjVrnBoT/1ySW8kKQbqS2UKOgPka5NvU=; b=hIbbsU8bieB+AjkpQD4RmLVKUuDPiA5sfijrgg+Vf6LCyscyUt7CY/ddx9GvBenAId Wf22cjWHFE9/Z0RYJCbdY7y8KkqFPRIbbDX3PWaJpfluerCpEaNeDd7hQ7VF20+70qBM YHZSUraU25HLd1gbJkbn5rIdct9CvHuUj65sY= 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; bh=P40dklr8M2mcjVrnBoT/1ySW8kKQbqS2UKOgPka5NvU=; b=RXLMESRF3TQjWLkfLPSs5ijszgQ4+XDaX9vkzyCgZoqm3YpZ8pMNL8WMEvlcBneLmT zNT+DEy5jDogHy9Jn9ZuSKMiN1+qAxl9Pild6BB8eHgPqwlFxAG86RgqrOiw7xRJjyxa 3mU/HAN87wGzfFwmXJFfRZ0EyxyNFhy/w4dkb7Mrki75c2n0Z5g5O29NvJaWryMCBdMD wL5+RqzNQVAg1Um3R6npZxmkz6OaSXswecmII+6a8Vi6CwAXq8C9KahkKYSGOD07oDAI 3XeT2Cph3HF5pK7XHRvpRRGF1L2cI5SzsLKJx6Mmirgx2+XVpp1sQd4tgmmb6802CsDo Hw3w== X-Gm-Message-State: ALyK8tIsKxNF6W5wNnsWeLzx/zgaIKfpXcQlJpdef2AoKiGSkeDwHqIJ3MhS6sMncM7xX54LJeZRKylwkK207iFk X-Received: by 10.107.9.10 with SMTP id j10mr4263180ioi.97.1464880626441; Thu, 02 Jun 2016 08:17:06 -0700 (PDT) MIME-Version: 1.0 References: <6238043.DCePXUsCVt@pintsize.usersys.redhat.com> In-Reply-To: From: David Benjamin Date: Thu, 02 Jun 2016 15:16:56 +0000 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a113f9b6a610b3605344d1965 Archived-At: Subject: Re: [TLS] Downgrade protection, fallbacks, and server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2016 15:17:19 -0000 --001a113f9b6a610b3605344d1965 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 2, 2016 at 10:59 AM Viktor Dukhovni wrote: > > > On Jun 2, 2016, at 10:49 AM, David Benjamin > wrote: > > > > I'm not sure I follow. The specification certainly spells out how > version negotiation is supposed to work. That hasn't stopped servers from > getting it wrong. Fundamentally this is the sort of thing where bugs don't > get noticed until we make a new TLS version, and we don't do that often > enough to keep rust from gathering. > > A better way to keep rust from gathering is to not instutionalize fallback, > force the broken sites to deal with the issue. While 2% is noticeable, you > can probably drive 1.3 version intolerance out of the ecosystem relatively > quickly if Chrome implements fallback for a limited time (say 6 months > after > TLS 1.3 RFC is done) and with a diminishing probability (60% first month, > 10% > less each month thereafter), season to taste. I've mused on something like that (I was the main driver behind painstakingly removing the existing version fallback in Chrome), but I don't think non-determinism is a good idea. Site owners need to be able to reproduce the failures their users see. But, yes, I will of course be monitoring the true metrics (my probing a list of sites is only an approximation) and seeing what can be done here, as I did previously. David --001a113f9b6a610b3605344d1965 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 2,= 2016 at 10:59 AM Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:

> On Jun 2, 2016, at 10:49 AM, David Benjamin <davidben@chromium.org> wrote: >
> I'm not sure I follow. The specification certainly spells out how = version negotiation is supposed to work. That hasn't stopped servers fr= om getting it wrong. Fundamentally this is the sort of thing where bugs don= 't get noticed until we make a new TLS version, and we don't do tha= t often enough to keep rust from gathering.

A better way to keep rust from gathering is to not instutionalize fallback,=
force the broken sites to deal with the issue.=C2=A0 While 2% is noticeable= , you
can probably drive 1.3 version intolerance out of the ecosystem relatively<= br> quickly if Chrome implements fallback for a limited time (say 6 months afte= r
TLS 1.3 RFC is done) and with a diminishing probability (60% first month, 1= 0%
less each month thereafter), season to taste.

I've mused on something like that (I= was the main driver behind painstakingly removing the existing version fal= lback in Chrome), but I don't think non-determinism is a good idea. Sit= e owners need to be able to reproduce the failures their users see.<= br>

But, yes, I will of course be monitoring the t= rue metrics (my probing a list of sites is only an approximation) and seein= g what can be done here, as I did previously.

Davi= d
--001a113f9b6a610b3605344d1965-- From nobody Thu Jun 2 08:20:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4D312D51A for ; Thu, 2 Jun 2016 08:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.348 X-Spam-Level: X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JK6eQznmSJa for ; Thu, 2 Jun 2016 08:20:48 -0700 (PDT) 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 CDDE312D1E4 for ; Thu, 2 Jun 2016 08:20:48 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 324A9D56EF; Thu, 2 Jun 2016 15:20:48 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-138.brq.redhat.com [10.34.0.138]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u52FKkVm031186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2016 11:20:47 -0400 From: Hubert Kario To: David Benjamin Date: Thu, 02 Jun 2016 17:20:35 +0200 Message-ID: <2454213.pazTbBCOtZ@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.10-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: References: <6238043.DCePXUsCVt@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6211702.YXWo4A68NB"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 02 Jun 2016 15:20:48 +0000 (UTC) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Downgrade protection, fallbacks, and server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2016 15:20:50 -0000 --nextPart6211702.YXWo4A68NB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 02 June 2016 14:49:52 David Benjamin wrote: > On Thu, Jun 2, 2016 at 6:40 AM Hubert Kario wrote= : > > On Wednesday 01 June 2016 22:29:06 David Benjamin wrote: > > > In case folks hoped we could bump the ClientHello version without= > > > those dreaded browser fallbacks, I have bad news. :-( 1.3 > > > intolerance > > > very much exists. (Maybe we should just give up on > > > ClientHello.version and use an extension? Extensions have rusted > > > less.) > > >=20 > > > I picked a large list of top sites and tried connecting to them. > > > Just > > > under 2% of them could handle a TLS 1.2 ClientHello, but not the > > > same > > > ClientHello with the version switched to 1.3 (no other changes, s= o > > > I > > > haven't tested a real 1.3 ClientHello). They're not unknown hosts= > > > either. I expect if you probe any top site list, you'll very > > > quickly > > > find some. > >=20 > > there are also servers which choke on large extensions (say 4096 bi= t > > DH client key share with 384 bit ECDH key share), so avoiding the > > bump in version number won't solve all the problems either... >=20 > TLS 1.3 doesn't require clients offer a KeyShare for all groups in th= e > first ClientHello. It costs a HelloRetryRequest and another > round-trip, but I think that's fine. Clients can limit FFDHE in the > initial ClientHello to servers they've spoken to before or something.= > For unknown servers, if you only predict a couple of EC groups, it > shouldn't blow it up too badly, but of course we'll just have to see.= isn't one of the main selling points of TLSv1.3 the 1RTT? and if 1RTT=20= doesn't work, you still have to do a fallback dance, to a modified=20 TLSv1.3 but you still do given that TLSv1.2 intolerance is not completely eradicated yet, there=20= will always be some servers that do not support any kind of extensions=20= or changes to client hello's that worked before (see the 256-512byte=20= Client Hello problems caused by cipher suite additions) =20 > (Or clients can just not bother with FFDHE to begin with. I don't see= > the point and am not very interested in implementing it at all.) quantum computing, and while you may not agree, NIST has a different=20= opinion on the matter and that's enough of a reason for many people > > Speaking of version number, does the text say that a server _MUST_ > > accept any version higher than the one that is specified in the RFC= , > > but reply with 0x03,0x04 in case it doesn't support any future > > version of the protocol? It would be nice to have some kind of > > stick for the broken implementations... >=20 > I'm not sure I follow. The specification certainly spells out how > version negotiation is supposed to work. That hasn't stopped servers > from getting it wrong. Fundamentally this is the sort of thing where > bugs don't get noticed until we make a new TLS version, and we don't > do that often enough to keep rust from gathering. yes, but I don't see it spelling out anywhere that a server MUST accept= =20 higher numbers, it just describes how the mechanism works up to this=20= point, not how it will continue to work =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 --nextPart6211702.YXWo4A68NB 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 iQIcBAABCgAGBQJXUE7DAAoJEJKo0bgB0vX1o1wQAJqFVJOjHszEYbXJsvVzjl6q F5GrMU7uyHegKxUmBc/c/Y13oyJnu+xTxRGrJeCu4v0tb+//tGOBuefBo1T/STnz UmSNi1kOPQsXCN53Kzo0Ui7GQ7QDHu3lhuyLmLt3nSPkIxFEMIu92JiUY3jAUnKi wa87A/GDVkKc5ZGW6EavJ/FW1y3qWYvQAYmrV8KZpF0dWztHOa+CmZYAhOWXSC2/ 6myFArGEtS+UUn54sJXaD6QHZm43S2jNHn7NPcgeCJnF2SAJEQmE140DTFtCak4V jSHQ7hZ1NP8NRuKu8ovuOUKplw0jLq6P3/futoValOIGIkEd5SWolE8yNlcYHpk9 pBT24LMXGVfTl43er88oh8220LU6gBfnLJzWpf1e0Nk0cwJux8NMwIc8ypfl9DGL /EMy+BjgoF4FJBbIKKntd2jcEQHUtapYdx5ScoZ2pjixzr9DOsJuQk3QjDXAvbHj xxItGYXGkyEv01GV90oaonQEfKB6nTLn09j+ZX1zSywUTyFbEgiPInkTzqVQlei1 vSkdqc16rUiMW3De7UmJeHazOzhfZwWBBuxLA16DzhTA8A7Yezs5IOgf9gq7a9ng 5I5+hoNTcng58Bu+BNAmOLBzwVl0RtqzI4tRQgvgRmRlSGnDv0Xa3IfJReZxJFus Bz6P7upjs0brxSa8P3vS =QGvt -----END PGP SIGNATURE----- --nextPart6211702.YXWo4A68NB-- From nobody Thu Jun 2 08:22:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A393912D5A2 for ; Thu, 2 Jun 2016 08:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TB2ocN1vQ9B for ; Thu, 2 Jun 2016 08:22:13 -0700 (PDT) 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 48DBC12D5A9 for ; Thu, 2 Jun 2016 08:22:13 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id k19so35698236ioi.3 for ; Thu, 02 Jun 2016 08:22:13 -0700 (PDT) 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; bh=aVvUoaBDD9t3cgs5lXpCrLp3GrIRtIAnrNcrZMAQdjo=; b=V1uVI/YraPtqiFD5WjIvLrTJv6ItjbjykB816OABWPnrUNGKmcFfuoCZRulcpvOckW R1eDoDdSzjkZmS6GWo8Ko2ifNcJbb/JHX7lL3xmf571c9WbGIKkRg1KduMAIimZzElkd 01U2LcrTMq0cBLQWCw+H3tuILuSF9mkY2AQjE= 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; bh=aVvUoaBDD9t3cgs5lXpCrLp3GrIRtIAnrNcrZMAQdjo=; b=ezwYEULivHUBcaIv+Gz5Rv2Mt/RBojAgodj/IFUjDTj7QdF7ToXGnrTv2JfbphaeCb aGRSRdZ0CpFvSS19+Xih3dbpaqk6xnFkyfyZbmrwV42ZD3fMzTa0sbEAO8ffNzlxdcke d3gPcdlUIdlV7n4SZwdEk0DKmpf4Vr9cbfglaRh2WwXaKwjxWfUGYY8BS5Scn2d9ZTUG MPhOIgEHun5dW2VKBWDfprpiwhutofmlXGOr8rE5czNSKFPeuJ7AANSH4X+MBx6qDm9f r47eb38Kp9WGSsFD3LhdYQnevxNwjgZm3hyhtxj7GW1EM+uFXlCu38/d8eDMZgVeSUH+ c2fg== X-Gm-Message-State: ALyK8tLX6znCMNXaG9bWb1Tf4MoUI2JLofM+oUcN8K1cUmawnV6AgArUAqGN5mAIOd1P826OlbACfg9YeeFsheqC X-Received: by 10.107.9.10 with SMTP id j10mr4294099ioi.97.1464880932509; Thu, 02 Jun 2016 08:22:12 -0700 (PDT) MIME-Version: 1.0 References: <1464852691.5804.1.camel@redhat.com> <3713097.ExV049UdFl@pintsize.usersys.redhat.com> In-Reply-To: From: David Benjamin Date: Thu, 02 Jun 2016 15:22:03 +0000 Message-ID: To: Hubert Kario , tls@ietf.org Content-Type: multipart/alternative; boundary=001a113f9b6a9f1cfd05344d2b63 Archived-At: Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2016 15:22:22 -0000 --001a113f9b6a9f1cfd05344d2b63 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 2, 2016 at 11:07 AM David Benjamin wrote: > On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario wrote: > >> On Thursday 02 June 2016 11:39:20 Yoav Nir wrote: >> > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos >> > > wrote:> >> > > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote: >> > >> 2% is actually pretty good, but I agree that we're going to need >> > >> fallback. >> > > >> > > Please not. Lets let these fallbacks die. Not every client is a >> > > browser. TLS 1.3 must be a protocol which doesn't require hacks to >> > > operate. CBC was removed, lets do the same for insecure fallbacks. >> > >> > Not every client is a browser, but some are. So what does the browser >> > do when a server resets the connection after seeing the ClientHello? >> > >> > Blank screen with a failure message? >> >> fallback to check if the connection failure is caused by TLSv1.3, and if >> it is, display error message and put the blame squarely on the server > > (We already do that, by the way. That's exactly what ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION in Chrome is.) > We browser folk hate these fallbacks just enough as much as you do, if not > more. I personally spent quite a lot of time and effort getting rid of it > in Chrome (and I'm happy to say, as of Chrome 50, I seem to have > succeeded). I'm sure my counterparts at Mozilla went through similar pains. > > But reality is what it is. The Law of the Internet is the last thing that > changed is blamed. We have a limited "budget" we can spend breaking things > (otherwise I'd have removed almost everything by now!) and there is no > chance I can break all the hosts I found. > > I have been reaching out to figure out the broken vendors, but this is a > slow process. It will not be flushed this out anytime soon. With TLS 1.3 as > it stands, I think a browser fallback in the short to medium term is a > certainty. (If your clients don't need it, then by all means don't add one! > I envy you.) > > David > --001a113f9b6a9f1cfd05344d2b63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 2,= 2016 at 11:07 AM David Benjamin <davidben@chromium.org> wrote:
On Thu, J= un 2, 2016 at 6:43 AM Hubert Kario <hkario@redhat.com> wrote:
On Thursday 02 June 2016 11:39:20 Yoav Nir wrote:
> > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos
> > <nmav@red= hat.com> wrote:>
> > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote:
> >> 2% is actually pretty good, but I agree that we're going = to need
> >> fallback.
> >
> > Please not. Lets let these fallbacks die. Not every client is a > > browser. TLS 1.3 must be a protocol which doesn't require hac= ks to
> > operate. CBC was removed, lets do the same for insecure fallbacks= .
>
> Not every client is a browser, but some are. So what does the browser<= br> > do when a server resets the connection after seeing the ClientHello? >
> Blank screen with a failure message?

fallback to check if the connection failure is caused by TLSv1.3, and if it is, display error message and put the blame squarely on the server

(We already do that, by= the way. That's exactly what ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION i= n Chrome is.)
=C2=A0
We browser folk hate these fallbac= ks just enough as much as you do, if not more. I personally spent quite a l= ot of time and effort getting rid of it in Chrome (and I'm happy to say= , as of Chrome 50, I seem to have succeeded). I'm sure my counterparts = at Mozilla went through similar pains.

But reality= is what it is. The Law of the Internet is the last thing that changed is b= lamed. We have a limited "budget" we can spend breaking things (o= therwise I'd have removed almost everything by now!) and there is no ch= ance I can break all the hosts I found.

I have bee= n reaching out to figure out the broken vendors, but this is a slow process= . It will not be flushed this out anytime soon. With TLS 1.3 as it stands, = I think a browser fallback in the short to medium term is a certainty. (If = your clients don't need it, then by all means don't add one! I envy= you.)
David
--001a113f9b6a9f1cfd05344d2b63-- From nobody Thu Jun 2 08:27:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383A912D5C3 for ; Thu, 2 Jun 2016 08:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id topuEhVLntPt for ; Thu, 2 Jun 2016 08:27:17 -0700 (PDT) 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 140CD12D111 for ; Thu, 2 Jun 2016 08:27:17 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id t40so49421515ioi.0 for ; Thu, 02 Jun 2016 08:27:16 -0700 (PDT) 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 :cc; bh=agyofZPP5Qzh1XOKG5RfIVEQtpAfQmo00gbLrJVfn4k=; b=fqXEPIGwRQJ3mQDqHq7eZYqrzdZiG+2f00mytmmYCRccpDuELIlopK4lS8cI1KH/Gj /jbZG6igsZywIH7yWBSE9pzEWCGKPmxFhk8kMnG5txHHn8V4wAYzt3qI/TqzuCQDhfrl yQdvZcaDNKk8uyd+VNdT8IWUyq6UQz5aB+Iis= 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:cc; bh=agyofZPP5Qzh1XOKG5RfIVEQtpAfQmo00gbLrJVfn4k=; b=dq6HINg1si1E/hgzfPQSJstL37REGVzLZdfpDEAoHqmfnlOykCCrtf4vBSSnK07hXb HyAvs7DmIFpFuqps2cv9G+L0Vqxi9ZjnkRR8M3GOuShWznzjvldM64XDB/xi8bU+SuVV CIFW0uyRKfJpsxeot063H1hv/4Oi785xI+HyTy3wSIeQkhlBiFOznfiC4PNCkEwGDt8w ombGy1YXuf6oqs8I+7h0KME/iYd0g5DAXkr4XLECwYqhG/ug2kIwBFgPTIv9UFlyzXVK dCUqOq3W44l90F6k8gPbQg0i1Rn16inSMVUhtNgK9qZJ1PYc3w18QNVpfzWqKxWpFx3A xFrA== X-Gm-Message-State: ALyK8tKjY/Js3+T+R820AcAcGJwVlBQaQJ+AKVWo8MRqT10iJG7jhfSnV6G/oXg+6VD765lvkfHoJb08y7fTb8Fq X-Received: by 10.107.173.66 with SMTP id w63mr4468467ioe.110.1464881236180; Thu, 02 Jun 2016 08:27:16 -0700 (PDT) MIME-Version: 1.0 References: <6238043.DCePXUsCVt@pintsize.usersys.redhat.com> <2454213.pazTbBCOtZ@pintsize.usersys.redhat.com> In-Reply-To: <2454213.pazTbBCOtZ@pintsize.usersys.redhat.com> From: David Benjamin Date: Thu, 02 Jun 2016 15:27:06 +0000 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=001a114467c2b8e8ad05344d3d5e Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Downgrade protection, fallbacks, and server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2016 15:27:19 -0000 --001a114467c2b8e8ad05344d3d5e Content-Type: text/plain; charset=UTF-8 On Thu, Jun 2, 2016 at 11:20 AM Hubert Kario wrote: > > > Speaking of version number, does the text say that a server _MUST_ > > > accept any version higher than the one that is specified in the RFC, > > > but reply with 0x03,0x04 in case it doesn't support any future > > > version of the protocol? It would be nice to have some kind of > > > stick for the broken implementations... > > > > I'm not sure I follow. The specification certainly spells out how > > version negotiation is supposed to work. That hasn't stopped servers > > from getting it wrong. Fundamentally this is the sort of thing where > > bugs don't get noticed until we make a new TLS version, and we don't > > do that often enough to keep rust from gathering. > > yes, but I don't see it spelling out anywhere that a server MUST accept > higher numbers, it just describes how the mechanism works up to this > point, not how it will continue to work > > I added an entry here a bit ago: https://tlswg.github.io/tls13-spec/#rfc.appendix.B.4 "When processing a ClientHello containing a version of { 3, 5 } or higher, do you respond with the highest common version of TLS rather than requiring an exact match?" The ServerHello section says: https://tlswg.github.io/tls13-spec/#rfc.section.6.3.1.2 "This field [server_version] will contain the lower of that suggested by the client in the ClientHello and the highest supported by the server. For this version of the specification, the version is { 3, 4 }. (See Appendix C for details about backward compatibility.)" Although the ClientHello section says: https://tlswg.github.io/tls13-spec/#rfc.section.6.3.1.1 "The version of the TLS protocol by which the client wishes to communicate during this session. This SHOULD be the latest (highest valued) version supported by the client. For this version of the specification, the version will be { 3, 4 }. (See Appendix C for details about backward compatibility.)" I'll go put together a PR to change that to say the highest version supported or something. "which the client wishes to communicate" is somewhat ambiguous... David --001a114467c2b8e8ad05344d3d5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 2,= 2016 at 11:20 AM Hubert Kario <hka= rio@redhat.com> wrote:
> > Speaking of version number, does the text say that a server _MUST= _
> > accept any version higher than the one that is specified in the R= FC,
> > but reply with 0x03,0x04 in case it doesn't support any futur= e
> > version of the protocol? It would be nice to have some kind of > > stick for the broken implementations...
>
> I'm not sure I follow. The specification certainly spells out how<= br> > version negotiation is supposed to work. That hasn't stopped serve= rs
> from getting it wrong. Fundamentally this is the sort of thing where > bugs don't get noticed until we make a new TLS version, and we don= 't
> do that often enough to keep rust from gathering.

yes, but I don't see it spelling out anywhere that a server MUST accept=
higher numbers, it just describes how the mechanism works up to this
point, not how it will continue to work


=
I added an entry here a bit ago:
"When processing a ClientHello containin= g a version of { 3, 5 } or higher, do you respond with the highest common v= ersion of TLS rather than requiring an exact match?"

The ServerHello section says:
"This field [server_version] will = contain the lower of that suggested by the client in the ClientHello and th= e highest supported by the server. For this version of the specification, t= he version is { 3, 4 }. (See Appendix C for details about backward compatib= ility.)"

Although the ClientHello section say= s:
"The version of the TLS protocol by which the client wishes to commun= icate during this session. This SHOULD be the latest (highest valued) versi= on supported by the client. For this version of the specification, the vers= ion will be { 3, 4 }. (See Appendix C for details about backward compatibil= ity.)"

I'll go put together a PR to chang= e that to say the highest version supported or something. "which the c= lient wishes to communicate" is somewhat ambiguous...

David
--001a114467c2b8e8ad05344d3d5e-- From nobody Thu Jun 2 08:28:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B02912D769 for ; Thu, 2 Jun 2016 08:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.348 X-Spam-Level: X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hzo0UccE8hM for ; Thu, 2 Jun 2016 08:28:17 -0700 (PDT) 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 C82A712D76A for ; Thu, 2 Jun 2016 08:28:17 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7DEB07F6A8; Thu, 2 Jun 2016 15:28:17 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-138.brq.redhat.com [10.34.0.138]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u52FSG8w003617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2016 11:28:17 -0400 From: Hubert Kario To: David Benjamin Date: Thu, 02 Jun 2016 17:28:15 +0200 Message-ID: <3427199.yLtZbr21AE@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.10-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: References: <3713097.ExV049UdFl@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1914464.UQ72xrpcKJ"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 02 Jun 2016 15:28:17 +0000 (UTC) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2016 15:28:19 -0000 --nextPart1914464.UQ72xrpcKJ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 02 June 2016 15:07:53 David Benjamin wrote: > On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario wrote= : > > On Thursday 02 June 2016 11:39:20 Yoav Nir wrote: > > > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos > > > > wrote:> > > > >=20 > > > > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote: > > > >> 2% is actually pretty good, but I agree that we're going to > > > >> need > > > >> fallback. > > > >=20 > > > > Please not. Lets let these fallbacks die. Not every client is a= > > > > browser. TLS 1.3 must be a protocol which doesn't require hacks= > > > > to > > > > operate. CBC was removed, lets do the same for insecure > > > > fallbacks. > > >=20 > > > Not every client is a browser, but some are. So what does the > > > browser > > > do when a server resets the connection after seeing the > > > ClientHello? > > >=20 > > > Blank screen with a failure message? > >=20 > > fallback to check if the connection failure is caused by TLSv1.3, > > and if it is, display error message and put the blame squarely on > > the server > We browser folk hate these fallbacks just enough as much as you do, i= f > not more. I personally spent quite a lot of time and effort getting > rid of it in Chrome (and I'm happy to say, as of Chrome 50, I seem to= > have succeeded). I'm sure my counterparts at Mozilla went through > similar pains. >=20 > But reality is what it is. The Law of the Internet is the last thing > that changed is blamed. We have a limited "budget" we can spend > breaking things (otherwise I'd have removed almost everything by > now!) and there is no chance I can break all the hosts I found. that's why I said that the browser should diagnose the issue and put th= e=20 blame where blame is due user can't make an informed decision if he or she is not informed,=20 printing "Alert: Fatal, invalid_parameter" or a "server aborted=20 connection" is not information needed to make the decision > I have been reaching out to figure out the broken vendors, but this i= s > a slow process. It will not be flushed this out anytime soon. With > TLS 1.3 as it stands, I think a browser fallback in the short to > medium term is a certainty. (If your clients don't need it, then by > all means don't add one! I envy you.) for customers that need it, we explain the problem and provide option t= o=20 override the maximum version supported to a lower one =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 --nextPart1914464.UQ72xrpcKJ 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 iQIcBAABCgAGBQJXUFCPAAoJEJKo0bgB0vX1J74P/ixyaxIHH8ZTki3NkHBX5yF6 ovyTQAaZDJxyPpqpn1UHnWp4k0AInF/KXuV5k7whoY9B0bXlEC1wTveCGqHXPUXf GeP5vqPwaNTe3jGCx+iJPAqNorJq4XEolRZ01yi8kpM9F048HUgldVLMx1FSlem2 SkNN9M9NBo6pLoE/khluphsXnDcurNJqCqpI/W1I+KvX+7SypBBIPYiYVTfEOcsa lXldxwy4iq32JdAyFtHgTO+kjVMfOwZUJAZfOli0Y1FdR9eLlgjt1tInq23H4nIb 46ixskrQ8tBlcT49rigYCKMZEg2Eer0Pr17WX/ky+dGUAhv6ISCJGjncySQtCPm7 QSSFtNTzbjd5Ky/8qxgwnyF9CTSh40qd74TAP5B4/DmroQryTXmeD/qaTYstRrX8 1Akv3bTdVIHHlzPMH2JR+D4DxQc7onyPAUEBu2a0bLT2Ujg4vNVdnBRtDbAdb0Su NPdfhE6m3vh2H3MpBA6dkM/F1TrSBx49DXeWlQUmZf+mpkr+nTbjN6NUXprtdcVK NciGTP8vlVmjfYjFmVnytjGO7jo7RWc5P/HcH+TUtWHzOXxNJa4XKPZMJ/+E/2Dp K6bkKKo3PfbvbXX6gmWYkdFcteqH/YjxwgQr0VBjrb9yqA/vxjEQRGHY6SzVX5Ih khFcB1WtaV9B/motjVsT =CPfG -----END PGP SIGNATURE----- --nextPart1914464.UQ72xrpcKJ-- From nobody Thu Jun 2 08:33:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2080812D778 for ; Thu, 2 Jun 2016 08:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.348 X-Spam-Level: X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOZPC88KGE2l for ; Thu, 2 Jun 2016 08:32:57 -0700 (PDT) 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 3C9CA12D76E for ; Thu, 2 Jun 2016 08:32:57 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E8840C00C91C; Thu, 2 Jun 2016 15:32:56 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-138.brq.redhat.com [10.34.0.138]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u52FWt3c021910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2016 11:32:56 -0400 From: Hubert Kario To: David Benjamin Date: Thu, 02 Jun 2016 17:32:55 +0200 Message-ID: <1572975.CxeTyXB7rM@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.10-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2139975.7phPDyiLET"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 02 Jun 2016 15:32:57 +0000 (UTC) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2016 15:32:59 -0000 --nextPart2139975.7phPDyiLET Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 02 June 2016 15:22:03 David Benjamin wrote: > On Thu, Jun 2, 2016 at 11:07 AM David Benjamin > wrote: > > On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario =20 wrote: > >> On Thursday 02 June 2016 11:39:20 Yoav Nir wrote: > >> > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos > >> > > wrote:> > >> > >=20 > >> > > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote: > >> > >> 2% is actually pretty good, but I agree that we're going to > >> > >> need > >> > >> fallback. > >> > >=20 > >> > > Please not. Lets let these fallbacks die. Not every client is = a > >> > > browser. TLS 1.3 must be a protocol which doesn't require hack= s > >> > > to > >> > > operate. CBC was removed, lets do the same for insecure > >> > > fallbacks. > >> >=20 > >> > Not every client is a browser, but some are. So what does the > >> > browser > >> > do when a server resets the connection after seeing the > >> > ClientHello? > >> >=20 > >> > Blank screen with a failure message? > >>=20 > >> fallback to check if the connection failure is caused by TLSv1.3, > >> and if it is, display error message and put the blame squarely on > >> the server > (We already do that, by the way. That's exactly what > ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION in Chrome is.) the rest of the information on such error page definitely doesn't give=20= that impression Correct me if I'm wrong, but isn't the full text on it: """ The web page at https://example.com might be temporarily down or it may= =20 have moved permanently to a new web address. Error code: ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION """ =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 --nextPart2139975.7phPDyiLET 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 iQIcBAABCgAGBQJXUFGnAAoJEJKo0bgB0vX1dXkP/2GvzPelHTDh3ZyIOLRWLPoh WhPly5wpg8xZFnivrioLSNM02z+Vj58R2Fp2e2FK4rTqdwhyib0iQbUeoWUPbQyV RRIHXQuN0nZsZ6ooOMu1zI4mgVC5Mqq9RmgezHmD6CWFgJw0midtgbVaM5u+YfOr JP3TCUs1gm8s7UHBuRCp44lxOmHeW6u3zph9u1Z81bcQt7H1pF6p4ZjpZhAoBwgr aIGNj5e04QuTFnseZeFOltIqGyqgss7isLGYrqACM9XUoT4ds/4+kVRyihPwLYFq ChxIb0OAdQTXIM9xjkb0OnBRt/6W0gfes0yhL5rye+j8G/G386ZLfYYJNy6pgk5v iYrCOwF94mOTmAHhR+0MtsCjlTfiGZm8ZIzWMJnNneDK73F+gLEp/UiZh0Fh821q FYuQcB0BVbAp+6nDRDbeT5pCMe1tUyXdxDdNE2YFbPRr2hanrRJGvZU8F+M9cEc9 b+q/ffQemcE/sz3YOrsp68SO3fIdJnfEjJjIw1zWXUJ7geJp9rOV1O9d+nPQfW6g oi7XPb1raqZqQQcImMWXA262YemS6fW2uZaHqE0h6uAbn1QWlxuHgeXHaeuvHwm0 GNagvfC+W+oTZBHLFPaIBAOOX/FdwTkfqoFTYKbYPkJ/tPlPXPwwJTvcuEskDpl2 U4bt0jAwg/M65ENXkcxA =7Oee -----END PGP SIGNATURE----- --nextPart2139975.7phPDyiLET-- From nobody Thu Jun 2 08:33:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5DB12D77D for ; Thu, 2 Jun 2016 08:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGZwNmo_DFrE for ; Thu, 2 Jun 2016 08:33:12 -0700 (PDT) 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 0240B12D77C for ; Thu, 2 Jun 2016 08:33:12 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id DDF63284B14 for ; Thu, 2 Jun 2016 15:33:10 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 2 Jun 2016 11:33:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6238043.DCePXUsCVt@pintsize.usersys.redhat.com> To: tls@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Downgrade protection, fallbacks, and server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jun 2016 15:33:15 -0000 > On Jun 2, 2016, at 11:16 AM, David Benjamin = wrote: >=20 > I've mused on something like that (I was the main driver behind = painstakingly removing the existing version fallback in Chrome), but I = don't think non-determinism is a good idea. Site owners need to be able = to reproduce the failures their users see. >=20 > But, yes, I will of course be monitoring the true metrics (my probing = a list of sites is only an approximation) and seeing what can be done = here, as I did previously. Opening a new window or tab and trying again a couple of times is not a major reproducibility barrier. The odds of failure would increase with time, and would not be small to start with. It would be important to roll the dice just once for a given site within a given window or tab (at least until the user navigates to a new = domain) so that once contact is successful, further disruption does not render = the site unusable. Basically, resume with the highest protocol that worked consistently until such state is safe to flush, but reduce the odds of initial success over a well publicized time-frame. --=20 Viktor. From nobody Thu Jun 2 20:29:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3EC12D1A0 for ; Thu, 2 Jun 2016 20:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7Wv0Uw0Kt2m for ; Thu, 2 Jun 2016 20:29:32 -0700 (PDT) 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 A16F512D15C for ; Thu, 2 Jun 2016 20:29:32 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id n63so48593484qkf.0 for ; Thu, 02 Jun 2016 20:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=hOxEj37AuKkbK3uvNHbtPTsjjDGTztRxO/lA6gtajhM=; b=u+vosmbXawSs2QgXj00FdbdMyEfyBJ8KAnxeozXaW6/Pmwjj1aO60DglKjLgX5yxEo rgzqVpt5ZhfYiJzFLLYqcryb/JmT3BAlG2T75VaD3Jocwxr6NIli66MrmjK/PGBSeLMz g8CVRnbP02F0j565Meo4AXQEfcCZloTDgAo4f4YUizOegmI5iwtsV6zd9gy2j4wYq/Wq NderUgRpHGD5KGJD7khFwPRV5wGjbkPngxRDqj3ugjHm3CjgbDEHHtgz5fguSch2liE3 3C/6cUkavN4MwJRLMZ2MSHR56rwfpj6vAQc3WPF/Belp7R08BuAMRS4nHd7+DjRnDQsv ah2g== 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; bh=hOxEj37AuKkbK3uvNHbtPTsjjDGTztRxO/lA6gtajhM=; b=jWnK3Foxfdf7Y94fZzzcejr4XrVKcJ42oAbsmBO0rFbu+jMxNc083lV10mZzxyi1v/ M6NiQL+v0y5T8c9AZyAnxAjZMjc0RvPvqszBMeflQNjDoZV+TKmJT3D0yKVac+GBQmZs 6PuUgdOnft+Jg42nUCq3p2hG4bmJPId5aegTJwPZt1FrJZROrZ2BH/JQPpR4SauGvqdX rmViCkvzyoSL46pvWcvd0GnvBSrPVCRL/yPOwj+LjclS4nTpLtE4/kzXaTuK6oVchzzm ZXH0n7zMYW6oMMh8JyDx7bDkNXLCggg7VnXnoe+OjL+JWoZEFWSM7tL3nSFJaLQ5xIf2 ggww== X-Gm-Message-State: ALyK8tLDPoIG0jVrQwQx8pUZym5N28e3yg+a+uTkeUMx7OfVsDC8a2GKcPH+lJnWA8/BrhAMXcl4kyvzYf4AoA== MIME-Version: 1.0 X-Received: by 10.55.135.7 with SMTP id j7mr1301845qkd.32.1464924571837; Thu, 02 Jun 2016 20:29:31 -0700 (PDT) Received: by 10.140.104.110 with HTTP; Thu, 2 Jun 2016 20:29:31 -0700 (PDT) In-Reply-To: References: <1464852691.5804.1.camel@redhat.com> <3713097.ExV049UdFl@pintsize.usersys.redhat.com> Date: Fri, 3 Jun 2016 13:29:31 +1000 Message-ID: From: Martin Thomson To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2016 03:29:35 -0000 On 3 June 2016 at 01:07, David Benjamin wrote: > But reality is what it is. The Law of the Internet is the last thing that > changed is blamed. We have a limited "budget" we can spend breaking things > (otherwise I'd have removed almost everything by now!) and there is no > chance I can break all the hosts I found. FWIW, I agree. This has a bit of an explanation of the forces at play here: https://annevankesteren.nl/2016/05/client-server From nobody Thu Jun 2 21:17:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0135C12B05F for ; Thu, 2 Jun 2016 21:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gi1ZYI9OZGM5 for ; Thu, 2 Jun 2016 21:17:23 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002: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 0A7BD12D15C for ; Thu, 2 Jun 2016 21:17:23 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id o16so69979425ywd.2 for ; Thu, 02 Jun 2016 21:17:22 -0700 (PDT) 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-transfer-encoding:message-id; bh=xFWBz/RD1GISFK6jf0/6QJO88elheyefu2Jge5rN5RE=; b=mFrLgrULop9lXf0esggz8flaUt+0DW1RcLJL8/qNILl3wx+0Y0whTI6jXtQ2flT9/x tdFJfoN1JMHLseLebVJ2ToGcQf3TdP0rQ+MJQj6b0egRadlJBL/vicjHLeCGYpD4iTHt gmRMnydaCSPXVeKovLEqq0fNWAhhSWXHLCeIaSlAgpUlJULDXUL7VNJj5Dn6TeiW3ZCN 9VIqC7c6C/VPj5tDf0CX+jqH6gcL2Im1ZrrAcYOyR83q+K7YiQJ8DEGTsEukpVvT04f/ KdBxjttFb/c5/fJBFZEEQ+wQaXyopJShl+6GdErcIsRzUZ4mmEbKphm43iUgnEcBSYTu +AnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=xFWBz/RD1GISFK6jf0/6QJO88elheyefu2Jge5rN5RE=; b=EZN0r0APouZauOKfwMtMaqIzvYozRhmIbSFgAMA2YlA18kuMhuhwNNsqd7ePU81+LV n0xkfp1aJ9KxN0L8FhY7BdrH0hYw1+uBpGJfLrcQDKAvpJVIHzd4jDMj7xUOj6UlriC6 tzlttXKqCIP2+pNCXrZMfYM76NkUOjrMphA0M8kLCZ7AG0uWlvJi7GSe+8Cnm+I71Q0O /xgjL4BI8weMvNQmZVyJEih2WFO8RAvgCG6BkQRZ38gEdbAp6CLPK4PasNwHaBjWKByK EEQbdgH3pxIS4KMc/GMRKodHMex0HIDZhQeI9wu5jz3oXrRD51W5UUjfziwY/lF8Ql4R Ld+w== X-Gm-Message-State: ALyK8tIhjKv1Q42ZZ7nT8XVMcmuYvknY2qZvXcrJBzjNVDTybxcmVcruuw7CVJG4K8uLxQ== X-Received: by 10.13.247.4 with SMTP id h4mr1152070ywf.118.1464927442341; Thu, 02 Jun 2016 21:17:22 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id w192sm2267741ywd.34.2016.06.02.21.17.21 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 02 Jun 2016 21:17:21 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 3 Jun 2016 00:17:20 -0400 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: <201606030017.20760.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2016 04:17:25 -0000 Allrighty then; time to dust off and rebase an old changeset I was fiddling with last year on this topic: https://github.com/davegarrett/tls13-spec/commit/058ff1518508b094b8c9f1bd4096be9393f20076 (I cleaned up a bit when rebasing, but it probably needs some work; was just a WIP branch, never a PR) This was the result of prior discussions on-list about TLS version intolerance. The gist of the proposal: 1) Freeze all the various version number fields. 2) Send a list of all supported versions in an extension. (version IDs converted to 16-bit ints instead of 8-bit pairs) 3) Use short (1 or 2 value, based on hello version) predefined lists for hellos from old clients not sending the extension. 4) Compare lists to find highest overlap, avoiding guesswork or problems with noncontinuous lists. 5) Forget the old mess of version intolerance existed. Do we want to consider scrapping the old version negotiation method again? Dave From nobody Thu Jun 2 22:36:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89AF12D571 for ; Thu, 2 Jun 2016 22:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.617 X-Spam-Level: X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UE5UFqx4EGaM for ; Thu, 2 Jun 2016 22:36:30 -0700 (PDT) Received: from BAY004-OMC3S20.hotmail.com (bay004-omc3s20.hotmail.com [65.54.190.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B95812D167 for ; Thu, 2 Jun 2016 22:36:30 -0700 (PDT) Received: from BAY405-EAS343 ([65.54.190.189]) by BAY004-OMC3S20.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 2 Jun 2016 22:36:29 -0700 X-TMN: [r8iQN9Qay60CNu8uOsiMGT+YuurNWz65] X-Originating-Email: [xiaoyin.l@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_5cb91698-73d5-4124-a5cb-bf500473f37e_" MIME-Version: 1.0 To: Dave Garrett , "tls@ietf.org" From: Xiaoyin Liu Date: Fri, 3 Jun 2016 13:36:27 +0800 Importance: normal X-Priority: 3 Thread-Topic: X-OriginalArrivalTime: 03 Jun 2016 05:36:29.0749 (UTC) FILETIME=[E124F650:01D1BD59] Archived-At: Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2016 05:36:32 -0000 --_5cb91698-73d5-4124-a5cb-bf500473f37e_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I strongly support this proposal. Best=2C Xiaoyin From: Dave Garrett Sent: Friday=2C June 3=2C 2016 12:17 To: tls@ietf.org Subject: Re: [TLS] no fallbacks please [was: Downgrade protection=2C fallba= cks=2C and server time] Allrighty then=3B time to dust off and rebase an old changeset I was fiddli= ng with last year on this topic: https://github.com/davegarrett/tls13-spec/commit/058ff1518508b094b8c9f1bd40= 96be9393f20076 (I cleaned up a bit when rebasing=2C but it probably needs some work=3B was= just a WIP branch=2C never a PR) This was the result of prior discussions on-list about TLS version intolera= nce. The gist of the proposal: 1) Freeze all the various version number fields. 2) Send a list of all supported versions in an extension. (version IDs conv= erted to 16-bit ints instead of 8-bit pairs) 3) Use short (1 or 2 value=2C based on hello version) predefined lists for = hellos from old clients not sending the extension. 4) Compare lists to find highest overlap=2C avoiding guesswork or problems = with noncontinuous lists. 5) Forget the old mess of version intolerance existed. Do we want to consider scrapping the old version negotiation method again? Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_5cb91698-73d5-4124-a5cb-bf500473f37e_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

I strongly support this proposal.

 =3B

Best=2C

Xiaoyin

 =3B

 =3B

 =3B

From: Dave Garrett
Sent: Friday=2C June 3=2C 2016 12:17
To: tls@ietf.org
Subject: Re: [TLS] no fallbacks please [was: Downgrade protection=2C= fallbacks=2C and server time]

 =3B

Allrighty then=3B time to dust off and rebase an o= ld changeset I was fiddling with last year on this topic:
https://github.com/davegarrett/tls13-spec/commit= /058ff1518508b094b8c9f1bd4096be9393f20076
(I cleaned up a bit when rebasing=2C but it probably needs some work=3B was= just a WIP branch=2C never a PR)

This was the result of prior discussions on-list about TLS version intolera= nce. The gist of the proposal:
1) Freeze all the various version number fields.
2) Send a list of all supported versions in an extension. (version IDs conv= erted to 16-bit ints instead of 8-bit pairs)
3) Use short (1 or 2 value=2C based on hello version) predefined lists for = hellos from old clients not sending the extension.
4) Compare lists to find highest overlap=2C avoiding guesswork or problems = with noncontinuous lists.
5) Forget the old mess of version intolerance existed.

Do we want to consider scrapping the old version negotiation method again?<= br>

Dave

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/= mailman/listinfo/tls
--_5cb91698-73d5-4124-a5cb-bf500473f37e_-- From nobody Thu Jun 2 23:37:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAFE12D640 for ; Thu, 2 Jun 2016 23:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.328 X-Spam-Level: X-Spam-Status: No, score=-8.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yx4vAad25ik5 for ; Thu, 2 Jun 2016 23:37:38 -0700 (PDT) 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 034B712D5D8 for ; Thu, 2 Jun 2016 23:37:37 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5AEE77DCC1; Fri, 3 Jun 2016 06:37:37 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.110]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u536bZ7Q030806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Jun 2016 02:37:36 -0400 Message-ID: <1464935854.2843.10.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Dave Garrett , tls@ietf.org Date: Fri, 03 Jun 2016 08:37:34 +0200 In-Reply-To: <201606030017.20760.davemgarrett@gmail.com> References: <201606030017.20760.davemgarrett@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Fri, 03 Jun 2016 06:37:37 +0000 (UTC) Archived-At: Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2016 06:37:40 -0000 On Fri, 2016-06-03 at 00:17 -0400, Dave Garrett wrote: > Allrighty then; time to dust off and rebase an old changeset I was > fiddling with last year on this topic: > https://github.com/davegarrett/tls13-spec/commit/058ff1518508b094b8c9 > f1bd4096be9393f20076 > (I cleaned up a bit when rebasing, but it probably needs some work; > was just a WIP branch, never a PR) > This was the result of prior discussions on-list about TLS version > intolerance. The gist of the proposal: > 1) Freeze all the various version number fields. > 2) Send a list of all supported versions in an extension. (version > IDs converted to 16-bit ints instead of 8-bit pairs) > 3) Use short (1 or 2 value, based on hello version) predefined lists > for hellos from old clients not sending the extension. > 4) Compare lists to find highest overlap, avoiding guesswork or > problems with noncontinuous lists. > 5) Forget the old mess of version intolerance existed. I had originally similar thoughts, but doesn't that introduce a 4th version negotiation mechanism? We already have the current version negotiation mechanism(1), the extension mechanism(2), the ciphersuite negotiation(3), and we are getting a new version negotiation mechanism based on extensions(4). Note that (1),(2) and (3) aren't getting away if we introduce (4). The code will stay in implementations for more than a decade. A simpler proposal is: Consider TLS 1.3 as a feature, and negotiate it using an empty extension. If the extension is present a server assumes TLS 1.3. regards, Nikos From nobody Fri Jun 3 01:34:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC1612B065 for ; Fri, 3 Jun 2016 01:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGRkb1kY4udt for ; Fri, 3 Jun 2016 01:33:59 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 58F7112B056 for ; Fri, 3 Jun 2016 01:33:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 3605939D3 for ; Fri, 3 Jun 2016 11:33:57 +0300 (EEST) 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 qc7NtmcPJPIm for ; Fri, 3 Jun 2016 11:33:55 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-224-2.bb.dnainternet.fi [87.100.224.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 984FE2310 for ; Fri, 3 Jun 2016 11:33:55 +0300 (EEST) Date: Fri, 3 Jun 2016 11:33:54 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160603083354.GA5321@LK-Perkele-V2.elisa-laajakaista.fi> References: <201606030017.20760.davemgarrett@gmail.com> <1464935854.2843.10.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1464935854.2843.10.camel@redhat.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2016 08:34:02 -0000 On Fri, Jun 03, 2016 at 08:37:34AM +0200, Nikos Mavrogiannopoulos wrote: > A simpler proposal is: > Consider TLS 1.3 as a feature, and negotiate it using an empty > extension. If the extension is present a server assumes TLS 1.3. Well, AFAIK, in current editor's draft, key_share or pre_shared_key is always present and none are meaningful in TLS.1.2. -Ilari From nobody Fri Jun 3 02:28:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBE912D12A for ; Fri, 3 Jun 2016 02:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.328 X-Spam-Level: X-Spam-Status: No, score=-8.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-BjI_YvMzI0 for ; Fri, 3 Jun 2016 02:28:13 -0700 (PDT) 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 58E9912D0CD for ; Fri, 3 Jun 2016 02:28:13 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 18F8428A48; Fri, 3 Jun 2016 09:28:13 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-148.brq.redhat.com [10.34.0.148]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u539SBRF007024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2016 05:28:12 -0400 From: Hubert Kario To: tls@ietf.org Date: Fri, 03 Jun 2016 11:28:05 +0200 Message-ID: <1706151.1Qo9uxO9Hr@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.11-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <1464935854.2843.10.camel@redhat.com> References: <201606030017.20760.davemgarrett@gmail.com> <1464935854.2843.10.camel@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2165237.Fj27SbfhKc"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 03 Jun 2016 09:28:13 +0000 (UTC) Archived-At: Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2016 09:28:15 -0000 --nextPart2165237.Fj27SbfhKc Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 03 June 2016 08:37:34 Nikos Mavrogiannopoulos wrote: > A simpler proposal is: > Consider TLS 1.3 as a feature, and negotiate it using an empty > extension. If the extension is present a server assumes TLS 1.3. If anything, it should be this. Extension with version negotiation introduced because version=20 negotiation is commonly gotten wrong doesn't look like a solution to=20= me... That being said, I would prefer the solution to be a compliance test=20= suite that checks if servers do handle correctly future versions, futur= e=20 extensions and future ciphersuites correctly. =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 --nextPart2165237.Fj27SbfhKc 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 iQIcBAABCgAGBQJXUU2lAAoJEJKo0bgB0vX1H0IQAKFAYu7yqz5XNlq3l3jsvQkf e/ns+jU28rXGwyz85C4al9+AH4xQog/iyT6Lxht+rU5RMLuRoXoUAGakehutnsmp QTxDuHFGyAihcsE7ITvyMOr09vSBPPLj6Y8tyjD+HesD/BG9zK7Rpx34g2tnvfaB MuTWlQIRG6b/gW2xfHVdwS2vedAhOFA7O1+ZFb52NldQO6La95OBg5wfQ4tVvEqE EafwPHnq/U3Yqg1OlgQm+3+5si4MAHq979MVpNhnrpRR4Bj3CRJXZKGtEA8uvjhb 5O6CQpnnYdlgo2R3+V7EpezKZ49dpHq0v4QDg1YFL4ow2qBGNrV7cjcw1abrI558 gcKRIJt3okKB5B+6PvvOiCLCGD/Uw7G7/iMGggA88hmyjADN+Z7Cp4A7jF28fM66 IVhfmk+tTb0eMzpiNuuVZiSgV/Llx3qGQndLhyPXCzwpU4Cmf2ro7UyA4yqYKskv VAsgzSm6UUORwUIQBnLWRjhGfZdZoHKyfhnmojXzF0P6JC3/cL6mrkJrIgxo0w7Q hTkM5o5aRSQnVEPSdg15FG/o2SpLTWqV90/2/zdYtyCszjoQUZDEzw7kbWuoOTrv DtMZXiAnG3jEMwc/1+wt57X3sZ+XYDCBUxRhtBPWTyAirHj2He8UJE0bIfH74a09 eLY3q87p1DfIAxLxjhWs =XgE9 -----END PGP SIGNATURE----- --nextPart2165237.Fj27SbfhKc-- From nobody Fri Jun 3 04:39:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B19112D117 for ; Fri, 3 Jun 2016 04:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77vT--v3k47G for ; Fri, 3 Jun 2016 04:39:07 -0700 (PDT) Received: from BAY004-OMC3S23.hotmail.com (bay004-omc3s23.hotmail.com [65.54.190.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21C012D118 for ; Fri, 3 Jun 2016 04:39:07 -0700 (PDT) Received: from BAY180-W68 ([65.54.190.188]) by BAY004-OMC3S23.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 3 Jun 2016 04:39:07 -0700 X-TMN: [P6aUwcGu7jKa8pWqQbRNYnOF/ajouuK/] X-Originating-Email: [xiaoyin.l@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_1720e5eb-c277-4f85-bd49-62b3fcd9a573_" From: Xiaoyin Liu To: Ilari Liusvaara , "tls@ietf.org" Date: Fri, 3 Jun 2016 07:39:06 -0400 Importance: Normal In-Reply-To: <20160603083354.GA5321@LK-Perkele-V2.elisa-laajakaista.fi> References: , , , <201606030017.20760.davemgarrett@gmail.com>, <1464935854.2843.10.camel@redhat.com>, <20160603083354.GA5321@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2016 11:39:07.0414 (UTC) FILETIME=[89B92B60:01D1BD8C] Archived-At: Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2016 11:39:12 -0000 --_1720e5eb-c277-4f85-bd49-62b3fcd9a573_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Date: Fri=2C 3 Jun 2016 11:33:54 +0300 > From: ilariliusvaara@welho.com > To: tls@ietf.org > Subject: Re: [TLS] no fallbacks please [was: Downgrade protection=2C fall= backs=2C and server time] >=20 > On Fri=2C Jun 03=2C 2016 at 08:37:34AM +0200=2C Nikos Mavrogiannopoulos w= rote: >=20 > > A simpler proposal is: > > Consider TLS 1.3 as a feature=2C and negotiate it using an empty > > extension. If the extension is present a server assumes TLS 1.3. >=20 > Well=2C AFAIK=2C in current editor's draft=2C key_share or pre_shared_key > is always present and none are meaningful in TLS.1.2. But they cannot be used to distinguish TLS 1.3 with any future versions=2C = if these two extensions still exist in TLS 1.4=2C 1.5=2C ... . Best=2CXiaoyin = --_1720e5eb-c277-4f85-bd49-62b3fcd9a573_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B Date: Fri=2C 3 Jun 2= 016 11:33:54 +0300
>=3B From: ilariliusvaara@welho.com
>=3B To: t= ls@ietf.org
>=3B Subject: Re: [TLS] no fallbacks please [was: Downgrad= e protection=2C fallbacks=2C and server time]
>=3B
>=3B On Fri= =2C Jun 03=2C 2016 at 08:37:34AM +0200=2C Nikos Mavrogiannopoulos wrote:>=3B
>=3B >=3B A simpler proposal is:
>=3B >=3B Consider = TLS 1.3 as a feature=2C and negotiate it using an empty
>=3B >=3B ex= tension. If the extension is present a server assumes TLS 1.3.
>=3B >=3B Well=2C AFAIK=2C in current editor's draft=2C key_share or pre_sha= red_key
>=3B is always present and none are meaningful in TLS.1.2.

But they cannot be used to distinguish TLS 1.3 = =3Bwith any future versions=2C if these two extensions still exist in TLS 1= .4=2C 1.5=2C ... .

Best=2C
Xiaoyin
= --_1720e5eb-c277-4f85-bd49-62b3fcd9a573_-- From nobody Fri Jun 3 06:29:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4C112D689 for ; Fri, 3 Jun 2016 06:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.328 X-Spam-Level: X-Spam-Status: No, score=-8.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMzh6x9BRsP0 for ; Fri, 3 Jun 2016 06:29:02 -0700 (PDT) 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 7FA5412D655 for ; Fri, 3 Jun 2016 06:29:02 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 14C2578224; Fri, 3 Jun 2016 13:29:02 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-148.brq.redhat.com [10.34.0.148]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u53DT03e008578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2016 09:29:01 -0400 From: Hubert Kario To: tls@ietf.org Date: Fri, 03 Jun 2016 15:28:59 +0200 Message-ID: <162793761.V3ugPeL6jJ@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.11-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: References: <20160603083354.GA5321@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1628447.pr4W9pdfyM"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 03 Jun 2016 13:29:02 +0000 (UTC) Archived-At: Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2016 13:29:05 -0000 --nextPart1628447.pr4W9pdfyM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 03 June 2016 07:39:06 Xiaoyin Liu wrote: > > Date: Fri, 3 Jun 2016 11:33:54 +0300 > > From: ilariliusvaara@welho.com > > To: tls@ietf.org > > Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, > > fallbacks, and server time]>=20 > > On Fri, Jun 03, 2016 at 08:37:34AM +0200, Nikos Mavrogiannopoulos=20= wrote: > > > A simpler proposal is: > > > Consider TLS 1.3 as a feature, and negotiate it using an empty > > > extension. If the extension is present a server assumes TLS 1.3. > >=20 > > Well, AFAIK, in current editor's draft, key_share or pre_shared_key= > > is always present and none are meaningful in TLS.1.2. >=20 > But they cannot be used to distinguish TLS 1.3 with any future > versions, if these two extensions still exist in TLS 1.4, 1.5, ... . TLSv1.4 and TLSv1.5 can introduce their own extensions, empty ones in=20= worst case =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 --nextPart1628447.pr4W9pdfyM 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 iQIcBAABCgAGBQJXUYYbAAoJEJKo0bgB0vX1YG4P/0YjwQ6xiR9Xhl5P+6xeNMch YwABb3BRjY1cZu5EtMbHzchF145luPVEfgPN9pu8wG169YW2wfSlU1pyaiVKGDVR J3c0PsL1gWShV5/2TKmHKlv1m9PGdEvQRa90WKtrHTKb4/Iygq17P/ZeBQh0iuUd Go7340q0cORK2bF8y05LsG7Zdr/eNYVWLv/XIzNnNbpPwzgrxvIW2BV7vEN51tmI kzQmequupVa9XQ/blVzUi9hh4Cdn/hKachOKOdB25QrC4meSfb5ibBd/DUnxY6f2 vrQy9XOA9bChT6CtUgWrjm8XD7C7tHdPX8TYOIpPJuXfRvdRZ6qP415gT/AOMCdR ymYefxkXqiWLVy1VJbcyiFI0+Fv37cIeM2H5NYuVeP4wBZULWdae4hc82n9e+o1/ snn4YH3YOxoP0D8Q7ot3o/lS/vF9RiFisczcmkTFffduuNa630PpPS7jeLIpek7S 3ap0R1yaKqm0SNpsmrrybWHWUAN8crxd24TksdeKz5pFgyM/0nIfOFCXwsAEg2NS DPh4KK4KSxE4AQoaaZXOWd2PYatAKlVx1+UNKUhAOef9i/dsmgkSVFpWtM1jJlKq Q9GNzAPUFiGkIPwVPzEFASr4qW4XmiB/YUiFyZ8kfUQtRQu1A2se+6E5nANf0IK/ nxcUo2krhw80W7Hh3nM3 =L6jQ -----END PGP SIGNATURE----- --nextPart1628447.pr4W9pdfyM-- From nobody Fri Jun 3 06:40:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924C112D1A4 for ; Fri, 3 Jun 2016 06:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxtan3UOfAH6 for ; Fri, 3 Jun 2016 06:40:45 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002: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 D525F12D69A for ; Fri, 3 Jun 2016 06:40:38 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id x189so80279476ywe.3 for ; Fri, 03 Jun 2016 06:40:38 -0700 (PDT) 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; bh=GAzFO+j0eydZ5AAxA1QFx7Qh+AGdqvM4CC7s0vRrRd4=; b=hSBVXIr/pI3Woo9lHuZa6HW6eiNPlx9FFBFFJCx2wF3+lFeSS12eZV0KQhkWi20MtF Vx6dvW/uNZutBHRvNud/4mr0QjnRgNI+3Eymb9vmz1AxLNAwzWiC/NNvVn1WgJ+Buoz2 WfZN6iBCt5V2aJkKneY0f+Log3gb09I8+tzGzKaG9Xls42ynM7uqbBB1D+XvkPJmeVTE iYdYwygiUzxyD2POEB/oNC3ZPpxUTXQ/L3TdSnYmJjU0K8WbUiF45HWsUM9p/lsS7pIL GGq8RXvI6qx2wlFgQjJOPsK+ore6wlyj7uplxmSNze2lCF9oAKwjFOAnbxJLo2hNObic 9JQg== 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; bh=GAzFO+j0eydZ5AAxA1QFx7Qh+AGdqvM4CC7s0vRrRd4=; b=DcFn2IMCLHCaiKp9RtV2Ikh/t4TzjJstJ38EOer6WT8LzZ3+fhVq9otzizZlhyuuKZ d5YQGabQbhO8uW21cGykkVhjgA9odyXmo1fd4Ixs9oE+Bc2nUdThGLqf9n/8eGFSBtG/ eLG9FsZ3g9Mp+jdQlCe6Cyh2jcWuISaoJ/QsNgTxyYGEeL/wG88E+xB2s3jNozwExHZ8 d6w1UjWyyAPvrxWEhWR7eZkvfIBQ4Euj1OjI70cuLw5yVr6/PXBPgMY53mu7MKY0qXdM WPfbhdILN2E38HqA/cEuGsdO2a/Kl0+Ng2EEWvCCBn8IgmPd6YP6r+SumWqxnwqobRPF VJIA== X-Gm-Message-State: ALyK8tJ/iT76ISWKg6LyqppLmqEmSt3EW5RBjalRwedK0g8i4uY5brR459RxwijiSgsy1eAHDbpEh/iMXgoaqQ== X-Received: by 10.129.4.8 with SMTP id 8mr2560138ywe.44.1464961238118; Fri, 03 Jun 2016 06:40:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.230.76 with HTTP; Fri, 3 Jun 2016 06:39:58 -0700 (PDT) In-Reply-To: <201606030017.20760.davemgarrett@gmail.com> References: <201606030017.20760.davemgarrett@gmail.com> From: Eric Rescorla Date: Fri, 3 Jun 2016 06:39:58 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a113f575c35693405345fdeb0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2016 13:40:47 -0000 --001a113f575c35693405345fdeb0 Content-Type: text/plain; charset=UTF-8 My opinion on this hasn't really changed since the last time. This seems like it's more complicated and it's not clear to me why it won't lead to exactly the same version intolerance problem in future. -Ekr On Thu, Jun 2, 2016 at 9:17 PM, Dave Garrett wrote: > Allrighty then; time to dust off and rebase an old changeset I was > fiddling with last year on this topic: > > https://github.com/davegarrett/tls13-spec/commit/058ff1518508b094b8c9f1bd4096be9393f20076 > (I cleaned up a bit when rebasing, but it probably needs some work; was > just a WIP branch, never a PR) > > This was the result of prior discussions on-list about TLS version > intolerance. The gist of the proposal: > 1) Freeze all the various version number fields. > 2) Send a list of all supported versions in an extension. (version IDs > converted to 16-bit ints instead of 8-bit pairs) > 3) Use short (1 or 2 value, based on hello version) predefined lists for > hellos from old clients not sending the extension. > 4) Compare lists to find highest overlap, avoiding guesswork or problems > with noncontinuous lists. > 5) Forget the old mess of version intolerance existed. > > Do we want to consider scrapping the old version negotiation method again? > > > Dave > --001a113f575c35693405345fdeb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My opinion on this hasn't really changed since th= e last time. This seems like it's more complicated and it's not cle= ar to me why it won't lead to exactly the same version intolerance prob= lem in future.

-Ekr


On Thu, Jun 2, 2016 at 9:17 PM, D= ave Garrett <davemgarrett@gmail.com> wrote:
Allrighty then; time to dust off and rebase an old c= hangeset I was fiddling with last year on this topic:
https://git= hub.com/davegarrett/tls13-spec/commit/058ff1518508b094b8c9f1bd4096be9393f20= 076
(I cleaned up a bit when rebasing, but it probably needs some work; was jus= t a WIP branch, never a PR)

This was the result of prior discussions on-list about TLS version intolera= nce. The gist of the proposal:
1) Freeze all the various version number fields.
2) Send a list of all supported versions in an extension. (version IDs conv= erted to 16-bit ints instead of 8-bit pairs)
3) Use short (1 or 2 value, based on hello version) predefined lists for he= llos from old clients not sending the extension.
4) Compare lists to find highest overlap, avoiding guesswork or problems wi= th noncontinuous lists.
5) Forget the old mess of version intolerance existed.

Do we want to consider scrapping the old version negotiation method again?<= br>

Dave

--001a113f575c35693405345fdeb0-- From nobody Fri Jun 3 10:28:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5793312D72A for ; Fri, 3 Jun 2016 10:28:23 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvJ4s7FsqW_U for ; Fri, 3 Jun 2016 10:28:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0101.outbound.protection.outlook.com [65.55.169.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D25A12D54C for ; Fri, 3 Jun 2016 10:28:20 -0700 (PDT) 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=yOSpZI1DE5sQIkDf41OJQT6TCvep2AQFZBIv6lCOsD4=; b=lNKKzp3CBL41EZPiuvZ+caCYtjXs5MSwad2dybGY13x/VkbmvCG2RkSmbfNVwfLkwrbN9eAaaoYVcQJwOlzTtv0wWjKI+1ydS7H0Oppyrvq4z4s7DZ6PkqC4DSEdZT4LHlDdHVsy81wfGk5U6cr6iVhEb50g6MzPT9KFeJlFG5g= Received: from BN3PR03MB1445.namprd03.prod.outlook.com (10.163.34.28) by BN3PR03MB1445.namprd03.prod.outlook.com (10.163.34.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.506.9; Fri, 3 Jun 2016 17:28:14 +0000 Received: from BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) by BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) with mapi id 15.01.0506.013; Fri, 3 Jun 2016 17:28:14 +0000 From: Andrei Popov To: Eric Rescorla , Dave Garrett Thread-Topic: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] Thread-Index: AQHRvOCeMmidP5FLoUi3Xegm0HRWy5/XFoaAgAANXACAAJ0zAIAAPvTg Date: Fri, 3 Jun 2016 17:28:14 +0000 Message-ID: References: <201606030017.20760.davemgarrett@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:c::1d2] x-ms-office365-filtering-correlation-id: 3e0a14da-a859-485c-296d-08d38bd471d0 x-microsoft-exchange-diagnostics: 1; BN3PR03MB1445; 5:iUR9J+ci6zYIu9tXX25Sye0/nshpByZT2AQ2ZV5EivVtnc7vILUICKlYa1+0AtLc9a4ZSd/bnMxDFAgyu2xMcwr5D4LIXYhTZwJnCvyRMboaXtoSBYBnoBh4tTV0cqYMthEyVUlk20AYXiXBCoOlCg==; 24:tuYY1RYE1DAvZxcprQibOTZ1TFtO09oN2F9jT3izW7yrZ25Mf5IQmfAZ81sylVqhXoYm8kd7d9+6C8Hr1SNsTa0dperRguKT6f3gSePSjyY=; 7:SUo5wW+cD4NFhJJdD2iFj95OG/BayaWaC1M2BgFRxsHIgcMsaYIxGpZ8Z/94NoofqucywzcCR/ks4WHpoUl5l38b/B+lhBhDpXnwQNLh4o7WdmuYXP96FkTsszvtb0hNVJVbk1nfg79xTlW6jvKXNdLm5euFXjV40KvAfU/UQzqDh5PPOoMkpzRAhEbBFC+27L6mtAgn3EXQ5FNLvrEoeLVZZcbivuiD73TMYjAoYhLYPofkH/c3ifPC+xGkMPXd x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1445; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR03MB1445; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1445; x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(81166006)(561944003)(8676002)(19617315012)(87936001)(77096005)(122556002)(76576001)(189998001)(19609705001)(9686002)(99286002)(15975445007)(3280700002)(19580405001)(8936002)(3660700001)(86362001)(5001770100001)(6116002)(790700001)(5003600100002)(10290500002)(5004730100002)(33656002)(5005710100001)(19580395003)(50986999)(92566002)(102836003)(54356999)(5002640100001)(10400500002)(19300405004)(4326007)(76176999)(93886004)(5008740100001)(19625215002)(106116001)(10090500001)(74316001)(2950100001)(16236675004)(586003)(11100500001)(2900100001)(2906002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1445; H:BN3PR03MB1445.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB1445B98411646620C45FDBEF8C590BN3PR03MB1445namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2016 17:28:14.4729 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1445 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2016 17:28:23 -0000 --_000_BN3PR03MB1445B98411646620C45FDBEF8C590BN3PR03MB1445namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXTigJlzIG5vdCB0aGF0IHRoZSBleGlzdGluZyB2ZXJzaW9uIG5lZ290aWF0aW9uIG1lY2hhbmlz bSBkb2VzbuKAmXQgd29yazsgdGhlIHByb2JsZW0gaXMgdGhhdCBpbXBsZW1lbnRlcnMgZ290IGl0 IHdyb25nLiBTaW1pbGFybHksIGltcGxlbWVudGVycyBjYW4gbWVzcyB1cCB0aGUgbmV3IG5lZ290 aWF0aW9uIG1lY2hhbmlzbS4gRXNwZWNpYWxseSBzaW5jZSB3ZSBoYXZlIHRvIHN1cHBvcnQgaXQg YXQgdGhlIHNhbWUgdGltZSBhcyB0aGUgb2xkIG9uZS4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0K RnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmlj IFJlc2NvcmxhDQpTZW50OiBGcmlkYXksIEp1bmUgMywgMjAxNiA2OjQwIEFNDQpUbzogRGF2ZSBH YXJyZXR0IDxkYXZlbWdhcnJldHRAZ21haWwuY29tPg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtUTFNdIG5vIGZhbGxiYWNrcyBwbGVhc2UgW3dhczogRG93bmdyYWRlIHByb3RlY3Rp b24sIGZhbGxiYWNrcywgYW5kIHNlcnZlciB0aW1lXQ0KDQpNeSBvcGluaW9uIG9uIHRoaXMgaGFz bid0IHJlYWxseSBjaGFuZ2VkIHNpbmNlIHRoZSBsYXN0IHRpbWUuIFRoaXMgc2VlbXMgbGlrZSBp dCdzIG1vcmUgY29tcGxpY2F0ZWQgYW5kIGl0J3Mgbm90IGNsZWFyIHRvIG1lIHdoeSBpdCB3b24n dCBsZWFkIHRvIGV4YWN0bHkgdGhlIHNhbWUgdmVyc2lvbiBpbnRvbGVyYW5jZSBwcm9ibGVtIGlu IGZ1dHVyZS4NCg0KLUVrcg0KDQoNCk9uIFRodSwgSnVuIDIsIDIwMTYgYXQgOToxNyBQTSwgRGF2 ZSBHYXJyZXR0IDxkYXZlbWdhcnJldHRAZ21haWwuY29tPG1haWx0bzpkYXZlbWdhcnJldHRAZ21h aWwuY29tPj4gd3JvdGU6DQpBbGxyaWdodHkgdGhlbjsgdGltZSB0byBkdXN0IG9mZiBhbmQgcmVi YXNlIGFuIG9sZCBjaGFuZ2VzZXQgSSB3YXMgZmlkZGxpbmcgd2l0aCBsYXN0IHllYXIgb24gdGhp cyB0b3BpYzoNCmh0dHBzOi8vZ2l0aHViLmNvbS9kYXZlZ2FycmV0dC90bHMxMy1zcGVjL2NvbW1p dC8wNThmZjE1MTg1MDhiMDk0YjhjOWYxYmQ0MDk2YmU5MzkzZjIwMDc2DQooSSBjbGVhbmVkIHVw IGEgYml0IHdoZW4gcmViYXNpbmcsIGJ1dCBpdCBwcm9iYWJseSBuZWVkcyBzb21lIHdvcms7IHdh cyBqdXN0IGEgV0lQIGJyYW5jaCwgbmV2ZXIgYSBQUikNCg0KVGhpcyB3YXMgdGhlIHJlc3VsdCBv ZiBwcmlvciBkaXNjdXNzaW9ucyBvbi1saXN0IGFib3V0IFRMUyB2ZXJzaW9uIGludG9sZXJhbmNl LiBUaGUgZ2lzdCBvZiB0aGUgcHJvcG9zYWw6DQoxKSBGcmVlemUgYWxsIHRoZSB2YXJpb3VzIHZl cnNpb24gbnVtYmVyIGZpZWxkcy4NCjIpIFNlbmQgYSBsaXN0IG9mIGFsbCBzdXBwb3J0ZWQgdmVy c2lvbnMgaW4gYW4gZXh0ZW5zaW9uLiAodmVyc2lvbiBJRHMgY29udmVydGVkIHRvIDE2LWJpdCBp bnRzIGluc3RlYWQgb2YgOC1iaXQgcGFpcnMpDQozKSBVc2Ugc2hvcnQgKDEgb3IgMiB2YWx1ZSwg YmFzZWQgb24gaGVsbG8gdmVyc2lvbikgcHJlZGVmaW5lZCBsaXN0cyBmb3IgaGVsbG9zIGZyb20g b2xkIGNsaWVudHMgbm90IHNlbmRpbmcgdGhlIGV4dGVuc2lvbi4NCjQpIENvbXBhcmUgbGlzdHMg dG8gZmluZCBoaWdoZXN0IG92ZXJsYXAsIGF2b2lkaW5nIGd1ZXNzd29yayBvciBwcm9ibGVtcyB3 aXRoIG5vbmNvbnRpbnVvdXMgbGlzdHMuDQo1KSBGb3JnZXQgdGhlIG9sZCBtZXNzIG9mIHZlcnNp b24gaW50b2xlcmFuY2UgZXhpc3RlZC4NCg0KRG8gd2Ugd2FudCB0byBjb25zaWRlciBzY3JhcHBp bmcgdGhlIG9sZCB2ZXJzaW9uIG5lZ290aWF0aW9uIG1ldGhvZCBhZ2Fpbj8NCg0KDQpEYXZlDQoN Cg== --_000_BN3PR03MB1445B98411646620C45FDBEF8C590BN3PR03MB1445namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SXTigJlzIG5vdCB0aGF0IHRoZSBleGlz dGluZyB2ZXJzaW9uIG5lZ290aWF0aW9uIG1lY2hhbmlzbSBkb2VzbuKAmXQgd29yazsgdGhlIHBy b2JsZW0gaXMgdGhhdCBpbXBsZW1lbnRlcnMgZ290IGl0IHdyb25nLiBTaW1pbGFybHksIGltcGxl bWVudGVycyBjYW4gbWVzcyB1cCB0aGUNCiBuZXcgbmVnb3RpYXRpb24gbWVjaGFuaXNtLiBFc3Bl Y2lhbGx5IHNpbmNlIHdlIGhhdmUgdG8gc3VwcG9ydCBpdCBhdCB0aGUgc2FtZSB0aW1lIGFzIHRo ZSBvbGQgb25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hl ZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kcmVpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVuZSAzLCAyMDE2 IDY6NDAgQU08YnI+DQo8Yj5Ubzo8L2I+IERhdmUgR2FycmV0dCAmbHQ7ZGF2ZW1nYXJyZXR0QGdt YWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW1RMU10gbm8gZmFsbGJhY2tzIHBsZWFzZSBbd2FzOiBEb3duZ3JhZGUgcHJvdGVj dGlvbiwgZmFsbGJhY2tzLCBhbmQgc2VydmVyIHRpbWVdPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IG9waW5pb24gb24gdGhpcyBoYXNuJ3QgcmVhbGx5IGNo YW5nZWQgc2luY2UgdGhlIGxhc3QgdGltZS4gVGhpcyBzZWVtcyBsaWtlIGl0J3MgbW9yZSBjb21w bGljYXRlZCBhbmQgaXQncyBub3QgY2xlYXIgdG8gbWUgd2h5IGl0IHdvbid0IGxlYWQgdG8gZXhh Y3RseSB0aGUgc2FtZSB2ZXJzaW9uIGludG9sZXJhbmNlIHByb2JsZW0gaW4gZnV0dXJlLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1biAyLCAyMDE2 IGF0IDk6MTcgUE0sIERhdmUgR2FycmV0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmVtZ2FycmV0 dEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kYXZlbWdhcnJldHRAZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QWxscmlnaHR5IHRoZW47IHRpbWUgdG8gZHVzdCBvZmYgYW5kIHJlYmFzZSBhbiBvbGQgY2hh bmdlc2V0IEkgd2FzIGZpZGRsaW5nIHdpdGggbGFzdCB5ZWFyIG9uIHRoaXMgdG9waWM6PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2RhdmVnYXJyZXR0L3RsczEzLXNwZWMvY29tbWl0 LzA1OGZmMTUxODUwOGIwOTRiOGM5ZjFiZDQwOTZiZTkzOTNmMjAwNzYiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL2dpdGh1Yi5jb20vZGF2ZWdhcnJldHQvdGxzMTMtc3BlYy9jb21taXQvMDU4ZmYx NTE4NTA4YjA5NGI4YzlmMWJkNDA5NmJlOTM5M2YyMDA3NjwvYT48YnI+DQooSSBjbGVhbmVkIHVw IGEgYml0IHdoZW4gcmViYXNpbmcsIGJ1dCBpdCBwcm9iYWJseSBuZWVkcyBzb21lIHdvcms7IHdh cyBqdXN0IGEgV0lQIGJyYW5jaCwgbmV2ZXIgYSBQUik8YnI+DQo8YnI+DQpUaGlzIHdhcyB0aGUg cmVzdWx0IG9mIHByaW9yIGRpc2N1c3Npb25zIG9uLWxpc3QgYWJvdXQgVExTIHZlcnNpb24gaW50 b2xlcmFuY2UuIFRoZSBnaXN0IG9mIHRoZSBwcm9wb3NhbDo8YnI+DQoxKSBGcmVlemUgYWxsIHRo ZSB2YXJpb3VzIHZlcnNpb24gbnVtYmVyIGZpZWxkcy48YnI+DQoyKSBTZW5kIGEgbGlzdCBvZiBh bGwgc3VwcG9ydGVkIHZlcnNpb25zIGluIGFuIGV4dGVuc2lvbi4gKHZlcnNpb24gSURzIGNvbnZl cnRlZCB0byAxNi1iaXQgaW50cyBpbnN0ZWFkIG9mIDgtYml0IHBhaXJzKTxicj4NCjMpIFVzZSBz aG9ydCAoMSBvciAyIHZhbHVlLCBiYXNlZCBvbiBoZWxsbyB2ZXJzaW9uKSBwcmVkZWZpbmVkIGxp c3RzIGZvciBoZWxsb3MgZnJvbSBvbGQgY2xpZW50cyBub3Qgc2VuZGluZyB0aGUgZXh0ZW5zaW9u Ljxicj4NCjQpIENvbXBhcmUgbGlzdHMgdG8gZmluZCBoaWdoZXN0IG92ZXJsYXAsIGF2b2lkaW5n IGd1ZXNzd29yayBvciBwcm9ibGVtcyB3aXRoIG5vbmNvbnRpbnVvdXMgbGlzdHMuPGJyPg0KNSkg Rm9yZ2V0IHRoZSBvbGQgbWVzcyBvZiB2ZXJzaW9uIGludG9sZXJhbmNlIGV4aXN0ZWQuPGJyPg0K PGJyPg0KRG8gd2Ugd2FudCB0byBjb25zaWRlciBzY3JhcHBpbmcgdGhlIG9sZCB2ZXJzaW9uIG5l Z290aWF0aW9uIG1ldGhvZCBhZ2Fpbj88YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+ PGJyPg0KPGJyPg0KRGF2ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN3PR03MB1445B98411646620C45FDBEF8C590BN3PR03MB1445namp_-- From nobody Fri Jun 3 10:33:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FC912D754 for ; Fri, 3 Jun 2016 10:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6bO6_WvZXCi for ; Fri, 3 Jun 2016 10:33:17 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 7A6E312D747 for ; Fri, 3 Jun 2016 10:33:17 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id h19so86877209ywc.0 for ; Fri, 03 Jun 2016 10:33:17 -0700 (PDT) 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; bh=ZGW0DNdz69OMvEk41vzrf+KZT5IanRsakvASLLhvhYY=; b=I9/fSQKmTVStY8SRoIJ2WP/9yotRh2hXvocQmvh2Q0fcT2lvfZ/RfCqb8dtneS6P90 09N+nHyoFok5bvHm3MqCTcFMtHmNl9MmTrZDRPZHaHYWiDBdxl3+HPfGH+9sa6pjzIj8 LZ2q+/xqEyviYDHkGuNCLcmMKiKWF3hfEQfzpZ22cVc7XNUjPGSZhQbmPIsftLCaYBEh qk8J8sAHFA0/aHgoA+SdA7tq8jMIcP9UKzbpw/+Eg2wMx+CRtOOEEat+lCkYi1tQBkkG V3X3WgdhE7vUuReD01cqZrM8eIWnHU5+w0CTQ988p+RF+AlX4lnOkYOAyZKC4V3jL+/X 9D7g== 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; bh=ZGW0DNdz69OMvEk41vzrf+KZT5IanRsakvASLLhvhYY=; b=CFMhAS/da/ux9ZIo0D7+YdgoGF3rWAZiUCDabUdubN3PQ+ZaXq+iKJqb89bMQPvTBE 6+CHrsNZ1wcqm+z1ZLu8lpiMRQA99rDwqb+aaadL4HYkIK70DT7dcz7Si1SJFXWsOnTF VXxKPeJtbDzEov+BSdAFpX9qt4OZhPTy5PSSZaftxNoo8S3MB2ASX4ms5435yVBjg0iZ eRTpmTTWrOrmddQR95H8pUuvQ010o7Vo8s9WY16CK9AOyEKpBQgtstzDm/UCg/ZDVsGB 2CXO8xZQC92PhXm0T3jGh9vuFez6hq4D1VYJTfKm2WCxpnVK9CSMUPZ9NjQq54qKJK1u jdYA== X-Gm-Message-State: ALyK8tJvk0k6wQlLmLz/PWLzZdXHRNoYwQeo+l8NOVHvTjWwx6Qy1lZPdF+sltKLOs/qrZEg02AFpvP//8NoYQ== X-Received: by 10.13.237.1 with SMTP id w1mr3184402ywe.62.1464975196759; Fri, 03 Jun 2016 10:33:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.230.76 with HTTP; Fri, 3 Jun 2016 10:32:37 -0700 (PDT) In-Reply-To: References: <201606030017.20760.davemgarrett@gmail.com> From: Eric Rescorla Date: Fri, 3 Jun 2016 10:32:37 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=94eb2c0864a8355f140534631e66 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2016 17:33:20 -0000 --94eb2c0864a8355f140534631e66 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's a clearer version of what I was trying to say. -Ekr On Fri, Jun 3, 2016 at 10:28 AM, Andrei Popov wrote: > It=E2=80=99s not that the existing version negotiation mechanism doesn=E2= =80=99t work; the > problem is that implementers got it wrong. Similarly, implementers can me= ss > up the new negotiation mechanism. Especially since we have to support it = at > the same time as the old one. > > > > Cheers, > > > > Andrei > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Friday, June 3, 2016 6:40 AM > *To:* Dave Garrett > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] no fallbacks please [was: Downgrade protection, > fallbacks, and server time] > > > > My opinion on this hasn't really changed since the last time. This seems > like it's more complicated and it's not clear to me why it won't lead to > exactly the same version intolerance problem in future. > > > > -Ekr > > > > > > On Thu, Jun 2, 2016 at 9:17 PM, Dave Garrett > wrote: > > Allrighty then; time to dust off and rebase an old changeset I was > fiddling with last year on this topic: > > https://github.com/davegarrett/tls13-spec/commit/058ff1518508b094b8c9f1bd= 4096be9393f20076 > (I cleaned up a bit when rebasing, but it probably needs some work; was > just a WIP branch, never a PR) > > This was the result of prior discussions on-list about TLS version > intolerance. The gist of the proposal: > 1) Freeze all the various version number fields. > 2) Send a list of all supported versions in an extension. (version IDs > converted to 16-bit ints instead of 8-bit pairs) > 3) Use short (1 or 2 value, based on hello version) predefined lists for > hellos from old clients not sending the extension. > 4) Compare lists to find highest overlap, avoiding guesswork or problems > with noncontinuous lists. > 5) Forget the old mess of version intolerance existed. > > Do we want to consider scrapping the old version negotiation method again= ? > > > Dave > > > --94eb2c0864a8355f140534631e66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's a clearer version of what I was trying to say.<= div>
-Ekr


On Fri, Jun 3, 2016 at 10:28 AM, Andrei Po= pov <Andrei.Popov@microsoft.com> wrote:

It=E2=80=99s not that the existing ve= rsion negotiation mechanism doesn=E2=80=99t work; the problem is that imple= menters got it wrong. Similarly, implementers can mess up the new negotiation mechanism. Especially since we have to support it at the s= ame time as the old one.

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Friday, June 3, 2016 6:40 AM
To: Dave Garrett <davemgarrett@gmail.com>
Cc: tls@ietf.org
Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, f= allbacks, and server time]

=C2=A0

My opinion on this hasn't really changed since t= he last time. This seems like it's more complicated and it's not cl= ear to me why it won't lead to exactly the same version intolerance pro= blem in future.

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Thu, Jun 2, 2016 at 9:17 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:

Allrighty then; time to dust off and rebase an old c= hangeset I was fiddling with last year on this topic:
https://github.com/davegarrett= /tls13-spec/commit/058ff1518508b094b8c9f1bd4096be9393f20076
(I cleaned up a bit when rebasing, but it probably needs some work; was jus= t a WIP branch, never a PR)

This was the result of prior discussions on-list about TLS version intolera= nce. The gist of the proposal:
1) Freeze all the various version number fields.
2) Send a list of all supported versions in an extension. (version IDs conv= erted to 16-bit ints instead of 8-bit pairs)
3) Use short (1 or 2 value, based on hello version) predefined lists for he= llos from old clients not sending the extension.
4) Compare lists to find highest overlap, avoiding guesswork or problems wi= th noncontinuous lists.
5) Forget the old mess of version intolerance existed.

Do we want to consider scrapping the old version negotiation method again?<= br>

Dave

=C2=A0


--94eb2c0864a8355f140534631e66-- From nobody Fri Jun 3 10:40:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDDF12D5D4 for ; Fri, 3 Jun 2016 10:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq-aPDug4fzO for ; Fri, 3 Jun 2016 10:40:52 -0700 (PDT) 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 14F5F12D5C4 for ; Fri, 3 Jun 2016 10:40:51 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D4E81284F26; Fri, 3 Jun 2016 17:40:50 +0000 (UTC) Date: Fri, 3 Jun 2016 17:40:50 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160603174050.GD3300@mournblade.imrryr.org> References: <201606030017.20760.davemgarrett@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] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jun 2016 17:40:54 -0000 On Fri, Jun 03, 2016 at 06:39:58AM -0700, Eric Rescorla wrote: > My opinion on this hasn't really changed since the last time. This seems > like it's more complicated and it's not clear to me why it won't lead to > exactly the same version intolerance problem in future. Doing version negotiation through extensions would be a major implementation burden. At present the client version appears early in the ClientHello at a fixed position in the packet, and the server can quickly grab the version, compute the highest shared version and branch to the protocol implementation for that version to parse the rest of the ClientHello. Putting the client version in an extension dramatically complicates server-side processing. So my view is that this would not be progress. This is IMNSHO even less likely to interoperate than what we have now. -- Viktor. From nobody Fri Jun 3 11:20:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1908D12D5FC for ; Fri, 3 Jun 2016 11:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agFZN4wP_ChE for ; Fri, 3 Jun 2016 11:20:03 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001: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 AFCC112D0AE for ; Fri, 3 Jun 2016 11:20:03 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id o189so71818739ioe.2 for ; Fri, 03 Jun 2016 11:20:03 -0700 (PDT) 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; bh=a8tNtndgfZ1z2c6K4tXj+K/ebWAha8WgwjMz3cFfzNM=; b=NXNJgQMnTNEf4baaDIwVtXxOVLu/LH9Ai430/RyxVMorMG21XfPF4nlBHTCDTDtxX3 rCu65Yc2yYIY62hA7hqyHCzh5rPwQ48jDu00GBCkhribmDLwkcWwn7savobyPRxBIBCQ /UoPYDvEX7R5FByb5X98fu/T0h6IpFp17qWuQ= 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; bh=a8tNtndgfZ1z2c6K4tXj+K/ebWAha8WgwjMz3cFfzNM=; b=WNliJa9+wvaPHuL78zGQoJS7I20yaRnYRUg08/1E+DDLj3NsofuAm4+QQZikHn+cyO recl9oV+MlL6mQC/H/xYtqxTN0eZVKd0LQsMDa9iZ7tuvtXBnjYZRkdkAPeC2kB3994G PXfsJgnH+xVBVZAqFYcuSoVh65l3wWdePGLtdU5C16t7hQH5Qm2pstKOV34+UPBq1ZOe gb4i3jVGmtSKG7N/aRqFVsQYyS4l0y4xiq/7BQY2MQY3GBHvX3rkNhlXDtxtrc1sAThp l4jagR9MQYB913+M66VFwg7UwZO56t+3wNAifYZnXrLsjrhm2XIUV7BHBLuq1mcZYeFV tMWw== X-Gm-Message-State: ALyK8tKjHE9hFNY0zhkhcoYTaJ/47Gbk1H+ScQnZrvRRw9enwdbu53wfpt6TovxbiQliUCTJuB6MT0JPTiwPma5K X-Received: by 10.107.52.16 with SMTP id b16mr7507374ioa.6.1464978002788; Fri, 03 Jun 2016 11:20:02 -0700 (PDT) MIME-Version: 1.0 References: <201606030017.20760.davemgarrett@gmail.com> <20160603174050.GD3300@mournblade.imrryr.org> In-Reply-To: <20160603174050.GD3300@mournblade.imrryr.org> From: David Benjamin Date: Fri, 03 Jun 2016 18:19:52 +0000 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a1144180e761584053463c521 Archived-At: Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2016 18:20:06 -0000 --001a1144180e761584053463c521 Content-Type: text/plain; charset=UTF-8 I think I could be convinced in either direction right now. It is definitely ugly and more of a nuisance to implement. The alternative is a fallback and then painfully driving it out later. We've done that before and we have FALLBACK_SCSV and the server_random trick now. At the same time, I am rather bored of this fallback game. We can actually avoid the intolerance problem with this mechanism. Suppose we used empty indicator extensions, one for each new version. Then as long as servers tolerate unknown extensions, we'll be fine. So far this has not rusted yet, and we can defend it from rust by having clients send random fake extensions out of a range of values we burn for this purpose[*] (or private use area). If one extension with a list of values, we can do something similar. (Strictly speaking, the version already does not appear at a fixed position because a ClientHello may be pathologically fragmented. OpenSSL even had CVE-2014-3511 here. I believe the master branch no longer has a sniff-based version negotiation. BoringSSL hasn't for a while now. But rejecting such pathologically fragmented ClientHellos is reasonable and OpenSSL 1.0.x does it now.) David [*] I'm planning on writing something up here soon. On Fri, Jun 3, 2016 at 1:40 PM Viktor Dukhovni wrote: > On Fri, Jun 03, 2016 at 06:39:58AM -0700, Eric Rescorla wrote: > > > My opinion on this hasn't really changed since the last time. This seems > > like it's more complicated and it's not clear to me why it won't lead to > > exactly the same version intolerance problem in future. > > Doing version negotiation through extensions would be a major > implementation burden. At present the client version appears early > in the ClientHello at a fixed position in the packet, and the server > can quickly grab the version, compute the highest shared version > and branch to the protocol implementation for that version to parse > the rest of the ClientHello. > > Putting the client version in an extension dramatically complicates > server-side processing. So my view is that this would not be > progress. This is IMNSHO even less likely to interoperate than > what we have now. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1144180e761584053463c521 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think I could be convinced in either direction right now= .

It is definitely ugly and more of a nuisance to implem= ent. The alternative is a fallback and then painfully driving it out later.= We've done that before and we have FALLBACK_SCSV and the server_random= trick now.

At the same time, I am rather bored of this = fallback game. We can actually avoid the intolerance problem with this mech= anism. Suppose we used empty indicator extensions, one for each new version= . Then as long as servers tolerate unknown extensions, we'll be fine. S= o far this has not rusted yet, and we can defend it from rust by having cli= ents send random fake extensions out of a range of values we burn for this = purpose[*] (or private use area). If one extension with a list of values, w= e can do something similar.

(Strictly speaking, th= e version already does not appear at a fixed position because a ClientHello= may be pathologically fragmented. OpenSSL even had CVE-2014-3511 here. I b= elieve the master branch no longer has a sniff-based version negotiation. B= oringSSL hasn't for a while now. But rejecting such pathologically frag= mented ClientHellos is reasonable and OpenSSL 1.0.x does it now.)

David

[*] I'm planning on writ= ing something up here soon.

On Fri, Jun 3, 2016 at 1:40 PM Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
On Fri, Jun 03, 2016 at 06:39:58AM -0700, E= ric Rescorla wrote:

> My opinion on this hasn't really changed since the last time. This= seems
> like it's more complicated and it's not clear to me why it won= 't lead to
> exactly the same version intolerance problem in future.

Doing version negotiation through extensions would be a major
implementation burden.=C2=A0 At present the client version appears early in the ClientHello at a fixed position in the packet, and the server
can quickly grab the version, compute the highest shared version
and branch to the protocol implementation for that version to parse
the rest of the ClientHello.

Putting the client version in an extension dramatically complicates
server-side processing.=C2=A0 So my view is that this would not be
progress.=C2=A0 This is IMNSHO even less likely to interoperate than
what we have now.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a1144180e761584053463c521-- From nobody Fri Jun 3 13:16:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6B112D165 for ; Fri, 3 Jun 2016 13:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okLAgpzGLOzW for ; Fri, 3 Jun 2016 13:16:17 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 23D0D12D100 for ; Fri, 3 Jun 2016 13:16:17 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id o16so90822794ywd.2 for ; Fri, 03 Jun 2016 13:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:cc :mime-version:content-transfer-encoding:message-id; bh=ELS173TNnKo/cbgYpTDZe6t7UOdxR4kGHU5ChRh2Kxo=; b=YpNSCjMURD/MSxcmKeexfcdrOuvCkp2KG+bj4gwtNAMVgyVp/G+2T/j2QYfJFXFoa5 W9UXujwPnioYBY74lzBZILy3SfGMuLGi0e5E28N0tK/Ivt++r/E7D7V218UNZfOTgRBg /Q2hWsjeB9+/gF7Hh6F+yGnbyjK4UEFmy/xlP+dr+cEhXfYHHj1fH4kIMwkZ2WE3Aumy dKiuzvGkzfHJurcPplzEpRkrsZHD2rk/T/qHpZiDMavs6ZFio4zLW/ShwbUHZ91XhmJA IJLmdRTHz9NjvSegJhbblYkDkbVX9RXu4YHPeUNC9f5QPYG2PVXZUO76CT1zyARPyTsb ebdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:references :in-reply-to:cc:mime-version:content-transfer-encoding:message-id; bh=ELS173TNnKo/cbgYpTDZe6t7UOdxR4kGHU5ChRh2Kxo=; b=LEKRsukE6xpo0MscZgvikgZL130oomY5ZD5AWiwVf/KcHxP8/zs38vcz72Lndtahh0 kZKeHYBtw9Dz/tU/oJhF1t2YeLP8AC+pTf4tdKkGUNwmZrhnDM3n9R3GPgG2fzrWwlsX WSvXAyXOEI2aoncAxDjfDc4LjhzNy/Hc3+jzzDSFPMkpZwjaO5TxloFJiA6anNeAYyAS P4p/bL3ba/DuRMXinxeVx0vPR7im6rRQF1cVXla932m5630gxYU2FmzYcML+zcAr/Coe kBUJjb0GvxvVF+mkqyI+cVmBkyWvVVTV/tSrBv2ypjBrWYE1ckpZZxqAVMhFk0XlE89W gqyQ== X-Gm-Message-State: ALyK8tJ/adchWs8Aq5kyxPDz5u5Nl4c5mXOt+XS9dJNzlGZV1B4vdu7a+e5M5HECDpKzXg== X-Received: by 10.37.76.133 with SMTP id z127mr3651851yba.152.1464984976293; Fri, 03 Jun 2016 13:16:16 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id a62sm4167753ywc.29.2016.06.03.13.16.15 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 03 Jun 2016 13:16:15 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 3 Jun 2016 16:16:13 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20160603174050.GD3300@mournblade.imrryr.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201606031616.14451.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2016 20:16:19 -0000 The idea of using an empty extension as an indicator really isn't fundamentally different from what I'm suggesting here. We'd just have an arbitrary set of new version indicators mixed in with extensions instead of inside a new generalized basket. My replacement was (again, it's over a year old) designed to be a general purpose long-term solution that could handle 1.3, 1.4, draft versions, experiments, etc, without special-casing. I'm not fundamentally against just adding a TLS 1.3 version indicator extension and freezing the old version number to 1.2. It just feels a little more hacky to me, though in the short-term it's simpler. With respect to the concern of version numbers being moved to a non-fixed position, we could just require that the new version list extension be first or last in the extensions list. Being required to be last would also permanently mitigate the known issue of some buggy servers choking with an empty extension last. Conversely, with an empty extension indicator for each 1.3+ version, we'd probably want to require that to be first in the list to avoid that bug. (servers would of course still have to parse as an extension as not all clients will be sending 1.3+, so it's not reliably placed like the current hello version) Dave On Friday, June 03, 2016 02:19:52 pm David Benjamin wrote: > I think I could be convinced in either direction right now. > > It is definitely ugly and more of a nuisance to implement. The alternative > is a fallback and then painfully driving it out later. We've done that > before and we have FALLBACK_SCSV and the server_random trick now. > > At the same time, I am rather bored of this fallback game. We can actually > avoid the intolerance problem with this mechanism. Suppose we used empty > indicator extensions, one for each new version. Then as long as servers > tolerate unknown extensions, we'll be fine. So far this has not rusted yet, > and we can defend it from rust by having clients send random fake > extensions out of a range of values we burn for this purpose[*] (or private > use area). If one extension with a list of values, we can do something > similar. > > (Strictly speaking, the version already does not appear at a fixed position > because a ClientHello may be pathologically fragmented. OpenSSL even had > CVE-2014-3511 here. I believe the master branch no longer has a sniff-based > version negotiation. BoringSSL hasn't for a while now. But rejecting such > pathologically fragmented ClientHellos is reasonable and OpenSSL 1.0.x does > it now.) > > David > > [*] I'm planning on writing something up here soon. > > On Fri, Jun 3, 2016 at 1:40 PM Viktor Dukhovni > wrote: > > > On Fri, Jun 03, 2016 at 06:39:58AM -0700, Eric Rescorla wrote: > > > My opinion on this hasn't really changed since the last time. This seems > > > like it's more complicated and it's not clear to me why it won't lead to > > > exactly the same version intolerance problem in future. > > > > Doing version negotiation through extensions would be a major > > implementation burden. At present the client version appears early > > in the ClientHello at a fixed position in the packet, and the server > > can quickly grab the version, compute the highest shared version > > and branch to the protocol implementation for that version to parse > > the rest of the ClientHello. > > > > Putting the client version in an extension dramatically complicates > > server-side processing. So my view is that this would not be > > progress. This is IMNSHO even less likely to interoperate than > > what we have now. From nobody Fri Jun 3 14:55:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E6A12D124 for ; Fri, 3 Jun 2016 14:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeXUoG-1S2Zy for ; Fri, 3 Jun 2016 14:55:14 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 B73A212D56D for ; Fri, 3 Jun 2016 14:55:13 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id 23so1522548qtq.0 for ; Fri, 03 Jun 2016 14:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=eTye4P9BfSc1h6WCrRdgDSOkKKQEv1JT1R4EKGQs2Mw=; b=XdxbcLM1S8kKt8vc3t8xyFPoQK0WmbOg3gXcOuKEIWw04v+uWGLwQAIZrXLyTE3mYc 4Lbxr84WMaScF4MJoohW0jz2GJBxk+txoCC6ZM+rOII51pEL1t3/MG82pBtP3/RKGGHF KIjrVkPpxz6qCkPu8RkL2RF1cpTPhWx0X62ONap4UGWLuKOzkOVeI/AjKWq5u3LJjhVR ROb/SZaQqMQ4kAqYCsvUSsqYPflweMY9tbcsOwBG/n9TMegu7hgwD3Ja/pnobpIRW4Lg WbFUPPZq08RCkOj+1B/780k4t29CrDDZT2gvRuznZA1acJx5l4uEr4WrjZx7QdKSjTFl onuA== 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; bh=eTye4P9BfSc1h6WCrRdgDSOkKKQEv1JT1R4EKGQs2Mw=; b=WV9ByPte7Su7vDHfSThLTo+Yb727cvbofix6y1e/eM79zC+IfhGL4x6QCDn6cBfx6g Li8yRAMwDRcl3LZr+wp1q15fgY8SzsfBWswpMNteU2dpmMZW2gAh8KwxsdzpnJkYpYsL F0YujuNNR73MgZdpp9H7SPpsTOCqHdw7lK8EqvyBHF8vlwhKHS3h6EtU5ILarRGOyEb9 bWg9r/HuzCDr0HLjFhq4UWI+JxYcjd7L1tX42CtLRmqyMU4ZqYiAamj+yg4QD7GOEwNR wHEenGyRCNCLDErxlco7UDJWKP4OK+E+VCr3IxehXio7Fo8ooenPaHZo5dF+qsQvPBak X4Yg== X-Gm-Message-State: ALyK8tJTZcat7a+zyHXqb4E5J9pdVrTE6nNFWLKgpWQyKEoRDVbZb3MdyQlHgdMUavyIDXpvONqNnabE0RGxjQ== X-Received: by 10.237.35.152 with SMTP id j24mr5554607qtc.95.1464990912732; Fri, 03 Jun 2016 14:55:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.175.196 with HTTP; Fri, 3 Jun 2016 14:54:53 -0700 (PDT) From: Joseph Salowey Date: Fri, 3 Jun 2016 14:54:53 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113c24caf40d90053466c698 Archived-At: Subject: [TLS] Closing on keys used for handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2016 21:55:17 -0000 --001a113c24caf40d90053466c698 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We still have a significant outstanding TLS 1.3 issue affecting involving which key to use for handshake and data records. Antoine Delignat-Lavaud, Bjoern Tackmann, Cas Cremers, Eric Rescorla, Felix Guenther and Markulf Kohlweiss put together a summary of the issue which is included below. We need to close on an approach to this issue so we can begin a final cryptographic review of the protocol. The plan is to have discussion of this issue for a week after which the chairs will start a week consensus call based on this discussion. After the chairs judge consensus, the author will produce a draft reflecting the consensus that can go out for review by the cryptographic community. Thanks, J&S BACKGROUND TLS 1.3 currently encrypts post-handshake handshake messages (NewSessionTicket, KeyUpdate, and post-handshake client authentication) with the application traffic keys. This makes it hard to do certain kinds of proofs, particularly cryptographic style proofs that make statements about the entire handshake (including encrypted post-handshake messages) being composable with application traffic. These proofs rely on having separate keys for these handshake-type messages and the application traffic. Unfortunately, the TLS record framing is not easily compatible with having multiple keys used simultaneously: because we encrypt the content type, it is not possible to use it to determine which key to use to decrypt. We examined a number of proposals which would allow you to simultaneously have encrypted content types and separate keys, but they all appear to be nonviable for one reason or another: - Trial decryption has serious implementation problems - Double-encrypting handshake messages in both the handshake key and the application key does not actually provide the required key separation - Separately encrypting the content type is inefficient in a number of ways, especially for DTLS (and would need separate security analysis). T= his is probably the most viable of the =E2=80=9Ctry to get both=E2=80=9D des= igns. This leaves us with two primary alternatives: 1. Use the same key (as in the current draft-13) 2. Restore a public content type and different keys I discuss these in a bit more detail below USE THE SAME KEY As stated above, using the same key for handshake and application traffic precludes certain types of proof. However, this is not to say that either it is insecure to use the same key or that no proof is possible. Specifically: - Using the same key is not an obstacle for symbolic proof methodologies. - In particular, if one is willing to restrict the proof of the handshake to the original handshake messages, then TLS 1.3 still provides key separation. - Hugo Krawczyk has a forthcoming paper which demonstrates the security of the current keying model using cryptographic techniques in a =E2=80=9Cse= cure channels=E2=80=9D model. Also, the miTLS proof of TLS 1.3 does not rely = on separation, as it considers the record protocol together with the handsh= ake. Nevertheless, there was broad and strong agreement at TRON that key separation considerably simplifies cryptographic proofs in the computational model by enabling modular analysis of handshake encryption and the record protocol. The motivation for switching keys from handshake to application traffic is somewhat undermined by late handshake messages being encrypted under the application traffic key. This can be viewed as a design compromise that breaks the separation principle for post-handshake messages while still incurring some of the overhead of separate keys in the handshake. PUBLIC CONTENT TYPES Clearly, having a public content type and separate keys for handshake and application data provides full key separation, at the cost of revealing whether a given record is handshake or application data (and potentially alerts). The major question that the group had was whether it was actually possible to conceal this information effectively, even with encrypted content types, since hiding the handshake messages in the application traffic requires detailed knowledge about the application traffic pattern (e.g., packet lengths, timing, response patterns, etc.). It=E2=80=99s clear= some analysis of this is needed. In addition, changing to public content types would potentially necessitate changes to the packet format: the current record design uses the fact that the content type is nonzero to overload it as a padding delimiter, and if we were to add a public content type, we would either need to duplicate the content type in both locations or remove the inner content type and find some new way to make the padding unambiguous. Note that because we already have a dummy content type, even having two copies would not make the packet longer currently, though we are hoping to eventually remove the external content type, in which case we might end up having the record not shrink by as much as one might like [0]. [0] There are probably designs that would actually let us keep the minimal packet size if we were willing to break the format on the wire. One potential design would be to retain the inner encrypted content type but rob a bit from the length (which currently has the first bit always set to low) to indicate which key is in use. --001a113c24caf40d90053466c698 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

We still have a significant outstanding TLS= 1.3 issue affecting involving which key to use for handshake and data reco= rds.=C2=A0 Antoine Delignat-Lavaud, Bjoern Tackmann, Cas Cremers, Eric Resc= orla, Felix Guenther and Markulf Kohlweiss put together a summary of the is= sue which is included below.=C2=A0 We need to close on an approach to this = issue so we can begin a final cryptographic review of the protocol.=C2=A0 T= he plan is to have discussion of this issue for a week after which the chai= rs will start a week consensus call based on this discussion.=C2=A0 After t= he chairs judge consensus, the author will produce a draft reflecting the c= onsensus that can go out for review by the cryptographic community.

Thanks,

J&S


BACKGROUND=

TLS 1.3 currently encrypts post-handshake handshake = messages (NewSessionTicket, KeyUpdate, and post-handshake client authentica= tion) with the application traffic keys. This makes it hard to do certain k= inds of proofs, particularly cryptographic style proofs that make statement= s about the entire handshake (including encrypted post-handshake messages) = being composable with application traffic. These proofs rely on having sepa= rate keys for these handshake-type messages and the application traffic.


Unfortunately, the TLS = record framing is not easily compatible with having multiple keys used simu= ltaneously: because we encrypt the content type, it is not possible to use = it to determine which key to use to decrypt. We examined a number of propos= als which would allow you to simultaneously have encrypted content types an= d separate keys, but they all appear to be nonviable for one reason or anot= her:


  • Trial decryption has serious implementation problems

  • Double-e= ncrypting handshake messages in both the handshake key and the application = key does not actually provide the required key separation

    • Separately encryptin= g the content type is inefficient in a number of ways, especially for DTLS = (and would need separate security analysis). This is probably the most viab= le of the =E2=80=9Ctry to get both=E2=80=9D designs.

This leaves us with two primary al= ternatives:


  1. Use the same key (as in the current draft-13)<= /span>

  2. = Restore a public content type and different keys


I discuss these in a bit more detail b= elow



USE THE SAME KEY

As stated above, using= the same key for handshake and application traffic precludes certain types= of proof. However, this is not to say that either it is insecure to use th= e same key or that no proof is possible. Specifically:


  • Using t= he same key is not an obstacle for symbolic proof methodologies.

    =

  • In particular= , if one is willing to restrict the proof of the handshake to the original = handshake messages, then TLS 1.3 still provides key separation.

    <= /li>

  • Hugo Krawczyk = has a forthcoming paper which demonstrates the security of the current keyi= ng model using cryptographic techniques in a =E2=80=9Csecure channels=E2=80= =9D model. Also, the miTLS proof of TLS 1.3 does not rely on separation, as= it considers the record protocol together with the handshake.


Nevertheless, there was = broad and strong agreement at TRON that key separation considerably simplif= ies cryptographic proofs in the computational model by enabling modular ana= lysis of handshake encryption and the record protocol. The motivation for s= witching keys from handshake to application traffic is somewhat undermined = by late handshake messages being encrypted under the application traffic ke= y. This can be viewed as a design compromise that breaks the separation pri= nciple for post-handshake messages while still incurring some of the overhe= ad of separate keys in the handshake.



PUBLIC CONTENT TYPES<= /p>

Clearly, having a public content type and separate keys for = handshake and application data provides full key separation, at the cost of= revealing whether a given record is handshake or application data (and pot= entially alerts). The major question that the group had was whether it was = actually possible to conceal this information effectively, even with encryp= ted content types, since hiding the handshake messages in the application t= raffic requires detailed knowledge about the application traffic pattern (e= .g., packet lengths, timing, response patterns, etc.). It=E2=80=99s clear s= ome analysis of this is needed.


In addition, changing to public content types would potentially n= ecessitate changes to the packet format: the current record design uses the= fact that the content type is nonzero to overload it as a padding delimite= r, and if we were to add a public content type, we would either need to dup= licate the content type in both locations or remove the inner content type = and find some new way to make the padding unambiguous. Note that because we= already have a dummy content type, even having two copies would not make t= he packet longer currently, though we are hoping to eventually remove the e= xternal content type, in which case we might end up having the record not s= hrink by as much as one might like [0].




[0] There are probably designs that would actually let us keep the mi= nimal packet size if we were willing to break the format on the wire. One p= otential design would be to retain the inner encrypted content type but rob= a bit from the length (which currently has the first bit always set to low= ) to indicate which key is in use.


<= /div> --001a113c24caf40d90053466c698-- From nobody Fri Jun 3 23:26:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638EB12B02B for ; Fri, 3 Jun 2016 23:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtAfKY77kw_0 for ; Fri, 3 Jun 2016 23:26:03 -0700 (PDT) Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com [IPv6:2607:f8b0:4002:c05::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 AF95312B009 for ; Fri, 3 Jun 2016 23:26:03 -0700 (PDT) Received: by mail-yw0-x244.google.com with SMTP id n16so13292207ywd.2 for ; Fri, 03 Jun 2016 23:26:03 -0700 (PDT) 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-transfer-encoding:message-id; bh=cs1X8qqtnBiMZTeSgLp6zW+zZcqGacn+DFlAhISbDAY=; b=xMnZex5LdsRlWQo1JsSZiaTUDf5Tb6suhAqoIpitObpywclt97MXYvkVLYDjyEfLHl jVydHPOR3oW/onIUHFkUNQVhk5gC/9BZFtphWkgm/mIiQUhFJizf8rwXUKSSKhGc5XbE CC7x1d2UQZBBB95N5/D1HuyT4X1MX7gb87wNQ+ARiTuCcBcuL2jhinMdXZRXpxE8Towy AiXlsvCGpuCaUgyrGlAFnNzxmZlUiydXNDfMYaUSozvpjMQXt6TGXyKKDgF/NLp0+N+0 U+aKScfl066IWbtoWA+1YwWkOKUhj1Q10AqsS46ZjkcoENkpoWHtaLnKwE7OIDTbypSa xqnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=cs1X8qqtnBiMZTeSgLp6zW+zZcqGacn+DFlAhISbDAY=; b=Xugbwtz3FaxkZUAQ+pvXSM3UKkZ4Zoaq4ZAz4wqNu5o3nmvuVtVHoNVvfjPVImYVb3 5zISwl/vKKfZDrMbL3rIqymOhtGlaYiYGqpH4nLUx+ujTuu+MKjt+bac5h05jh8E41Ew xxDmx3U/ttbW3GytSoUKptfDW1YnqM0MuRUiWkbeGLJA+P2x7tByf42GW/w+QPAkkVMH yhCrZ//Ue6zq3N9iD4eGtx4Kfl6BeiZGoJbJyFfNIu5jINZCgK4eWKebd1hJKahOOATj ySYhNsGEpq2ncCoUcOYu5aKmwnxFmOuJskY5TkRvCwBah+GAYgmZlQWFy3q4WkSrZDeO Bb1g== X-Gm-Message-State: ALyK8tLEWoZnDNXGjCL1bgo+pIGzUXSzYU3XpQfHs78Km9BslkMB7+HriwNzJ7eOgdRY+Q== X-Received: by 10.37.13.146 with SMTP id 140mr4976165ybn.112.1465021562993; Fri, 03 Jun 2016 23:26:02 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id w185sm5489424ywe.1.2016.06.03.23.26.02 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 03 Jun 2016 23:26:02 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sat, 4 Jun 2016 02:26:00 -0400 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: quoted-printable Message-Id: <201606040226.00867.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Closing on keys used for handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2016 06:26:05 -0000 On Friday, June 03, 2016 05:54:53 pm Joseph Salowey wrote: > Unfortunately, the TLS record framing is not easily compatible with having > multiple keys used simultaneously: because we encrypt the content type, it > is not possible to use it to determine which key to use to decrypt. We > examined a number of proposals which would allow you to simultaneously ha= ve > encrypted content types and separate keys, but they all appear to be > nonviable for one reason or another: >=20 > - Trial decryption has serious implementation problems > - Double-encrypting handshake messages in both the handshake key and t= he > application key does not actually provide the required key separation > - Separately encrypting the content type is inefficient in a number of > ways, especially for DTLS (and would need separate security analysis).= This > is probably the most viable of the =E2=80=9Ctry to get both=E2=80=9D d= esigns. Could someone please elaborate on why nested encryption would be a problem?= No objection to avoiding trial decryption, though. The general expectation I would have for doing double encryption here would= be to encrypt TLSCiphertext normally with the application traffic key and = TLSCiphertext.content would be the real unencrypted length plus an aead-cip= hered struct of the message which is encrypted with the relevant key. (the = unencrypted length would be the inner encrypted block's length, in this sce= nario) Dave From nobody Sat Jun 4 02:51:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADF912D152 for ; Sat, 4 Jun 2016 02:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ev_8CdrzcaDF for ; Sat, 4 Jun 2016 02:51:15 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id D97D712D10D for ; Sat, 4 Jun 2016 02:51:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 8207414E1 for ; Sat, 4 Jun 2016 12:51:12 +0300 (EEST) 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 gIpxgofBZ2R7 for ; Sat, 4 Jun 2016 12:51:12 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-224-2.bb.dnainternet.fi [87.100.224.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 2C945C4 for ; Sat, 4 Jun 2016 12:51:12 +0300 (EEST) Date: Sat, 4 Jun 2016 12:51:11 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160604095111.GA6537@LK-Perkele-V2.elisa-laajakaista.fi> References: <201606040226.00867.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201606040226.00867.davemgarrett@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Closing on keys used for handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2016 09:51:18 -0000 On Sat, Jun 04, 2016 at 02:26:00AM -0400, Dave Garrett wrote: > On Friday, June 03, 2016 05:54:53 pm Joseph Salowey wrote: > > Unfortunately, the TLS record framing is not easily compatible with having > > multiple keys used simultaneously: because we encrypt the content type, it > > is not possible to use it to determine which key to use to decrypt. We > > examined a number of proposals which would allow you to simultaneously have > > encrypted content types and separate keys, but they all appear to be > > nonviable for one reason or another: > > > > - Trial decryption has serious implementation problems > > - Double-encrypting handshake messages in both the handshake key and the > > application key does not actually provide the required key separation > > - Separately encrypting the content type is inefficient in a number of > > ways, especially for DTLS (and would need separate security analysis). This > > is probably the most viable of the “try to get both†designs. > > Could someone please elaborate on why nested encryption would be a > problem? The problem is that nested encryption does not solve the separation problem (application misusing keys it has[1] in ways that interact badly with the (late) handshake[2]). Essentially the difference is "the generated key is safe to use with any protocol" versus "the generated key is safe to use for TLS 1.3". And if the first is not true, proving the second is harder (even if it should be true, barring massive design errors[3] or applications doing utterly crazy stuff[4]). [1] Nevermind it REALLY SHOULD NOT actually have those keys, but only plaintext access to its own mux stream. [2] In normal TLS operation, the protocol mux/demux prevents such interference from actually occuring. [3] Like grossly broken protocol mux. [4] Stuff applications have absolutely no legimate business of doing (if I ever see such things, my first assumption about the cause will be malice). -Ilari From nobody Sat Jun 4 08:09:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B95612D178 for ; Sat, 4 Jun 2016 08:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRxAE_hMA-01 for ; Sat, 4 Jun 2016 08:09:07 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5FF12D135 for ; Sat, 4 Jun 2016 08:09:06 -0700 (PDT) Received: from [88.128.80.97] (helo=Williams-MacBook-Pro.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1b9DC1-0002zv-DQ; Sat, 04 Jun 2016 11:08:55 -0400 Date: Sat, 4 Jun 2016 08:08:44 -0700 From: Bill Frantz To: Hubert Kario X-Priority: 3 In-Reply-To: <1706151.1Qo9uxO9Hr@pintsize.usersys.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79c722cc726fb7d133989b007cf0bcc59c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 88.128.80.97 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2016 15:09:09 -0000 On 6/3/16 at 2:28 AM, hkario@redhat.com (Hubert Kario) wrote: >That being said, I would prefer the solution to be a compliance=20 >test suite that checks if servers do handle correctly future=20 >versions, future extensions and future ciphersuites correctly. I agree with Hubert. The big question is how you get the bug=20 report to the server operator. With servers which are currently maintained, it should be=20 possible, although difficult in specific instances to contact=20 the owner. With servers which aren't being maintained, e.g.=20 those in imbedded devices, the problem becomes much harder. If the client has a UI, it could explain the problem to the user=20 and ask if the user wants to continue with degraded security. If=20 so, then always use the remembered highest supported version=20 with that server domain name, with perhaps occasional reminders=20 to the user of the situation. In any case, we should be addressing our efforts to getting bugs=20 fixed, not just coding around them. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | The first thing you need when | Periwinkle (408)356-8506 | using a perimeter defense is a | 16345=20 Englewood Ave www.pwpconsult.com | perimeter. | Los Gatos,=20 CA 95032 From nobody Sat Jun 4 08:52:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856C5128E19 for ; Sat, 4 Jun 2016 08:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNUzQWZ-W_Bu for ; Sat, 4 Jun 2016 08:52:03 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 7A6C712D1D5 for ; Sat, 4 Jun 2016 08:52:03 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id c127so106184205ywb.1 for ; Sat, 04 Jun 2016 08:52:03 -0700 (PDT) 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; bh=AZqptI3xWArA1KCXzdMO6/hiEdUO/k6Yakh0/AA0hJM=; b=OBpQi31T3Dc1IAXrY3VAwWHPKT468II4v7A7Xf1utamwJnBElVk7yZ5o7i+cHclvag mIBClc6TZRwjBTkWhtnny3aODAjjk9DXFJV/R42g8VdGboDKp/HHEGoaYdOyW1Z3tz/R 8j31WJbZWSc1kEDLS2Lgx45AmoAw+BjmroVIHFwewbqCiuvN2LpGoSRs3y4mIaYUKZ8J w5aAHEAHWHYQhA/SetoeosJ+mcNctxSo4vT3O5rkrwhtGbV82xCx1htYZcCe8qZPQGvF KJbsF0I//0qdnMexVi71vssfFiXCjLtEErfBKKljcU5uL8ZwpsSYTz5fiPQX1VQE14VS Xlbw== 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; bh=AZqptI3xWArA1KCXzdMO6/hiEdUO/k6Yakh0/AA0hJM=; b=DtL9r1wU+QmfCd5DRTNAIzDsuA2SU6xwXHX7L+3iwxV7gvOn2qX3B0JNjd6Ei/PMez Yo7jtmAEPufwqQrLznaDpvx1xBUsYNI+c3YtRIXOiY36vrkAmin4kgp8MVZ8lpVRfRJz AB9mOzT6FhmAwFjh89JCujyos2Gek7do//6FrF1tjgaqPQ9lnTRu/CxcMxZsB1XllMB9 8iqb6VD5fatEKZxhPrszezQtqDQureCi9vhw+qLrOIMNRTe068B+hQDGnQyqJHXh60Hl deNzvuD3ESReUQK/6ItnRrRcVCIilr/8eTsSghxexqlCVlOBMmMqVOPqjy3z1yIugnyX vC/Q== X-Gm-Message-State: ALyK8tLmJLunoe9vyJTPI6Q0Zv0EwUzc4Xv8uWqGJJP/yiVRoTTZyeGIztzXFNwLokp+9TaH8nj1Tp2F2oxmVw== X-Received: by 10.13.233.1 with SMTP id s1mr6108857ywe.286.1465055522659; Sat, 04 Jun 2016 08:52:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.230.76 with HTTP; Sat, 4 Jun 2016 08:51:23 -0700 (PDT) From: Eric Rescorla Date: Sat, 4 Jun 2016 08:51:23 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c07cfb4018b59053475d225 Archived-At: Subject: [TLS] PR #493: Multiple concurrent tickets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2016 15:52:05 -0000 --94eb2c07cfb4018b59053475d225 Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/pull/493 Currently the server can send multiple tickets but we don't say anything about the semantics. So, say a server sends tickets T_1, T_2, T_3... T_n, and the client wants to initiate m < n connections, should he use: - only T_n - T_1...T_m - T_n, T_n-1, ... T_n-m+1 The intuition I have had is that we want the third option (latest wins, but allow multiples for linkability) but the spec doesn't say and there aren't any semantics that tell you, so I think we want some way for the server to say "these group of tickets are all co-valid". I've just created PR#493, which provides an explicit mechanism for this, "ticket generations". Tickets with the same generation M are co-valid and a ticket with generation N expires all tickets with generation M < N. The nice thing about this encoding is that a client can implement the old "one ticket at a time" behavior by just ignoring the generation and taking the last ticket. I wanted to call out to cryptographers/analysts that this formalizes the existing practice (going back to RFC 5077) of having multiple ticket values tied to the same basic secret (though less so with 1.3 because tickets issued on connection N+1 don't have the same RMS as those on connection N). If there is a problem with this, that would be good to know. Barring major objections, I'll merge this Thursday. -Ekr --94eb2c07cfb4018b59053475d225 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Currently the server can send multiple tickets but we don't say anyt= hing about the semantics.
So, say a server sends tickets T_1,= T_2, T_3... T_n, and the client wants to initiate m < n connections, sh= ould he use:

- only T_n
- T_1...T_m
<= /div>
- T_n, T_n-1, ... T_n-m+1

The intuition = I have had is that we want the third option (latest wins, but allow multipl= es for linkability) but the spec doesn't say and there aren't any s= emantics that tell you, so I think we want some way for the server to say &= quot;these group of tickets are all co-valid".

I've just created PR#493, which provides an explicit mechanism for th= is, "ticket generations". Tickets with the same generation M are = co-valid and a ticket with generation N expires all tickets with generation= M < N. The nice thing about this encoding is that a client can implemen= t the old "one ticket at a time" behavior by just ignoring the ge= neration and taking the last ticket.

I wanted to c= all out to cryptographers/analysts that this formalizes the existing practi= ce (going back to RFC 5077) of having multiple ticket values tied to the sa= me basic secret (though less so with 1.3 because tickets issued on connecti= on N+1 don't have the same RMS as those on connection N). If there is a= problem with this, that would be good to know.

Barring major objections, I'll merge this Thursday.


-Ekr


--94eb2c07cfb4018b59053475d225-- From nobody Sat Jun 4 09:21:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4712212D0B8 for ; Sat, 4 Jun 2016 09:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08I8Ju3looxT for ; Sat, 4 Jun 2016 09:21:43 -0700 (PDT) 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 89CDC12D0F1 for ; Sat, 4 Jun 2016 09:21:42 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id a136so35484870wme.0 for ; Sat, 04 Jun 2016 09:21:42 -0700 (PDT) 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-transfer-encoding; bh=wUTi7+bcpSuY6Ozno4QvvRPgrbyCAq0Fya8ODLHtMfQ=; b=XnhdRwwsI/MAa2mKNoLpuCXGyJBJCDV+AZXKR1Uz650M41+/c+6VfhV9OSOYdvsR+9 7syC/OclaDuR9s6rtVYLqAgJZ5ho1y9drMHDe1cj7dvz00txpFyaf0shNAVuhZBCvkOY y2EmuuZTxgC10oCirXUJGy1JXadxwnTcF1wGPnwDcphzzp7oQ0tVwdv6i1eHCiBZaf8M SAV1ZKyfNIkf+Sdy4x4ThMhY7X2p8X5RpEmZWIA7Kz1UQBq2wIwmzYCN5X2dhk+N53Ej fBQtqciwLsvqKfow32kZawiogW4pJgj/825ZcrIKZyYbxSRfYQV3TOHUeLAmWcIEHUxL DDOw== 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-transfer-encoding; bh=wUTi7+bcpSuY6Ozno4QvvRPgrbyCAq0Fya8ODLHtMfQ=; b=cF4/x0uEVg2eUgXArYKSmC7ipL71a5PBs8jc0Ay9n37CPxFWvgG3Wnxp9B90YCq1f6 RapW15eivXs960Xo28kmz32Vj5rGQmQSrKlSLqjMhxxwEwJdIfyloYptPepubw3E+K1e sNlVt2lEftmywBCmw3fWSZFLVoAibA69uyBThwvJ6PI/vd/CPNyuVF6vcL85sAWAzLJQ 6Tiab+FQ51cbYltLVGbrmwFI5L+TiRFTsn9h2Y/0S+Ev+dFKH70MdCK+OWOcI+oemH/w Uu8FHGqGdg+/yjGr7/EY+QwYil6xzBMofXGPLTxffFWo9B9mLEWO1q4GPdNVNRR4pKes QtMQ== X-Gm-Message-State: ALyK8tK1QiNODqXP7q7G7HGvrcWA46x/I/Y728+vWXIzwmkmPp+iWqU+3SMg0dTbd0SzqA== X-Received: by 10.194.201.162 with SMTP id kb2mr9146661wjc.55.1465057300992; Sat, 04 Jun 2016 09:21:40 -0700 (PDT) Received: from [10.0.0.9] (bzq-109-67-2-59.red.bezeqint.net. [109.67.2.59]) by smtp.gmail.com with ESMTPSA id y1sm11295489wjl.31.2016.06.04.09.21.39 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Jun 2016 09:21:39 -0700 (PDT) To: Eric Rescorla , "tls@ietf.org" References: From: Yaron Sheffer Message-ID: <57530011.50905@gmail.com> Date: Sat, 4 Jun 2016 19:21:37 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.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] PR #493: Multiple concurrent tickets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2016 16:21:45 -0000 Hi EKR, This is confusing: on the one hand you encourage clients to use multiple tickets when available, "to the extent possible use a different one for each new connection", and on the other hand you say that a simple way to follow the Generation policy is to keep only the latest ticket, and then presumably to use it multiple times. Can you please expand on the motivation here? Do we assume that a browser normally opens (say) 5 connections concurrently and we want each one to use fresh/separate key material? If so, maybe the client should indicate how much concurrency it plans to use? I think we would all be happier if the security proofs hold even if clients use the same ticket again and again. Thanks, Yaron On 04/06/16 18:51, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/pull/493 > > Currently the server can send multiple tickets but we don't say anything > about the semantics. > So, say a server sends tickets T_1, T_2, T_3... T_n, and the client > wants to initiate m < n connections, should he use: > > - only T_n > - T_1...T_m > - T_n, T_n-1, ... T_n-m+1 > > The intuition I have had is that we want the third option (latest wins, > but allow multiples for linkability) but the spec doesn't say and there > aren't any semantics that tell you, so I think we want some way for the > server to say "these group of tickets are all co-valid". > > I've just created PR#493, which provides an explicit mechanism for this, > "ticket generations". Tickets with the same generation M are co-valid > and a ticket with generation N expires all tickets with generation M < > N. The nice thing about this encoding is that a client can implement the > old "one ticket at a time" behavior by just ignoring the generation and > taking the last ticket. > > I wanted to call out to cryptographers/analysts that this formalizes the > existing practice (going back to RFC 5077) of having multiple ticket > values tied to the same basic secret (though less so with 1.3 because > tickets issued on connection N+1 don't have the same RMS as those on > connection N). If there is a problem with this, that would be good to know. > > Barring major objections, I'll merge this Thursday. > > > -Ekr > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sat Jun 4 09:46:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0673E12D522 for ; Sat, 4 Jun 2016 09:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zz-zAmiMrvHX for ; Sat, 4 Jun 2016 09:46:14 -0700 (PDT) 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 D176E12D1A3 for ; Sat, 4 Jun 2016 09:46:13 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id s131so14678415wme.0 for ; Sat, 04 Jun 2016 09:46:13 -0700 (PDT) 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-transfer-encoding; bh=MCR5rl5jrWAP93qvmm6174r2Ewz9/INQ9S0Mxm7jdtQ=; b=sICc26eUFUtAVVAryn5kHARlvz8MOBc3Lid2Uwr1URvp4jrOcour6HXmia+NY/rTei 6uE3I/4iqRYlobwmMGmO+9pHA34xNZ0yAHCmkk8I5wnxkHeavQEeOvgl1pU3hWURrBAh SNlbX6WURCg06dpv8VyiI29RSIwPLB0R30mnpENFYzyucrpyy1bJcp7oTS1icPHCvuF2 bqncAJ6ovzmWEFNLeLYDgg4Q7ignZ6ML+qoijwjrsWlIKPWTQ/DY63SmzCKexSJlllf/ EMvw2jhn2PaWN11bpVPEjMeQzmiqYohYfiB37DTnLPNV0kr2TDoUYNkQO5dKQnwGnYHT i05Q== 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-transfer-encoding; bh=MCR5rl5jrWAP93qvmm6174r2Ewz9/INQ9S0Mxm7jdtQ=; b=d4nkkHPZaQTIgVGNHJ4btOOAfQDU7Ji3qtzSUVubVLc+09tUYnxWbz2pALOEsrtSjn sBPfCX65af/szhvmL3zyGI4UB3MQGHzcXnZ/PMQPklypNnc6SBCeKY8JHqh61zKX+rBp ZuDz0icVU8gGVYm+ZvbV5dUbmDdF9APazvIWGVjLdvORuaU8sjZPG4pNx5qPDRgGeItl H0BzXxg9f+VXo8ol9If8SG7kGi3DP81FQ+sBFELjguyeNG0Ch/MU4ETIMC0/tPST5SLW 6LS5cz5BGd/FxvV/sfuzfXv+M/fn0GfouMx4cJidD5XptTdyT7HZNDiOWJzypes6c+9Q xTPg== X-Gm-Message-State: ALyK8tILJAif89TkzhICThj5L6Z7OqI1nSPu2GVdQXo4pB8H5tafZAs+IWMC6gCZfLo52w== X-Received: by 10.194.3.51 with SMTP id 19mr9003711wjz.57.1465058772325; Sat, 04 Jun 2016 09:46:12 -0700 (PDT) Received: from [10.0.0.9] (bzq-109-67-2-59.red.bezeqint.net. [109.67.2.59]) by smtp.gmail.com with ESMTPSA id lr9sm11367574wjb.39.2016.06.04.09.46.10 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Jun 2016 09:46:11 -0700 (PDT) To: David Benjamin , tls@ietf.org References: <6238043.DCePXUsCVt@pintsize.usersys.redhat.com> From: Yaron Sheffer Message-ID: <575305D1.3030709@gmail.com> Date: Sat, 4 Jun 2016 19:46:09 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.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] Downgrade protection, fallbacks, and server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2016 16:46:16 -0000 On 02/06/16 18:16, David Benjamin wrote: > On Thu, Jun 2, 2016 at 10:59 AM Viktor Dukhovni > wrote: > > > > On Jun 2, 2016, at 10:49 AM, David Benjamin > > wrote: > > > > I'm not sure I follow. The specification certainly spells out how > version negotiation is supposed to work. That hasn't stopped servers > from getting it wrong. Fundamentally this is the sort of thing where > bugs don't get noticed until we make a new TLS version, and we don't > do that often enough to keep rust from gathering. > > A better way to keep rust from gathering is to not instutionalize > fallback, > force the broken sites to deal with the issue. While 2% is > noticeable, you > can probably drive 1.3 version intolerance out of the ecosystem > relatively > quickly if Chrome implements fallback for a limited time (say 6 > months after > TLS 1.3 RFC is done) and with a diminishing probability (60% first > month, 10% > less each month thereafter), season to taste. > > > I've mused on something like that (I was the main driver behind > painstakingly removing the existing version fallback in Chrome), but I > don't think non-determinism is a good idea. Site owners need to be able > to reproduce the failures their users see. > > But, yes, I will of course be monitoring the true metrics (my probing a > list of sites is only an approximation) and seeing what can be done > here, as I did previously. > > David > Taking Viktor's proposal in a different direction, you could gradually increase the probability of version intolerance on the client side while still remaining deterministic from the user's point of view. You could do it by choosing a random distribution over server names (e.g., a hash of the SNI value). This means every month a few new servers would break. And you would want the client's beta channel to run several steps ahead of the production version. Thanks, Yaron From nobody Sat Jun 4 09:49:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94B612D53B for ; Sat, 4 Jun 2016 09:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flY53-TAWqYS for ; Sat, 4 Jun 2016 09:49:22 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 ED6D612D522 for ; Sat, 4 Jun 2016 09:49:21 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id o16so107048478ywd.2 for ; Sat, 04 Jun 2016 09:49:21 -0700 (PDT) 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; bh=Rq60+yvlEoqupn5CakM0nox0FM0XeJ08ysCmI9wTuOY=; b=vxSbqKDl+q9jlihUkVzjZ9kpZrSO9TSXtmTOVtMt4EX+aU/W9dyuO4cit9aRKFUewE 0AJQXQUxkEt4+MUrHPbOIMPRQkiGJnj/BWGPVz1sMJi3cNK/XWfU02HxNCSUCwhUpXoF xH2pM3RcZBlLg7qO3gUr0x/O5mbyTfwencE4PGTz4TmRW5Uav8qtw0UqrYfpWTPqGbRH vHV1m1r2mHGramUD4oq22Gii6t8g9Xku+BQ5a4oi/Newj4VgjCPYxMhCzdOj8bI2uH/b 7RzxlfEmOdKlU590QsVy39pSBPu5UYzx40/gX7XTk4NJinETwIgwPqVksW6ZGqo7EE9H y5Dw== 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; bh=Rq60+yvlEoqupn5CakM0nox0FM0XeJ08ysCmI9wTuOY=; b=RrXhvHfZcycadAgyGFGbvR16gwNMsj2OEnCLs419+JSUfvEgBc0HfvA6G+cOcSfjFV tjK3vn/tF6UCWt0a3pQ01Lbl01UDWdmO92Fqz5n1+FWaLsg3WpmMF5MC1OzU4LHYFqNd hKNX8wdvwZvOEqgAvL8yC0svK7PipudBkl/j88bLx8c4oI2hnDmCX7cn9DHgjr6uVAFz M8lN1ii0XL4aIVzznqvMDGOByNCraYG/q/a1e3wMItB0/F1/YE1BBcQfHc4FeIaNBsgc KmUEFEBqJRq8hXIWiVyVodEWtE54t/M++jWhbYxea/QH9FTGw0OsVCxZ8V1Lgl9nd4N6 U15A== X-Gm-Message-State: ALyK8tIQ2u5M+dCHPM1N0AqGRrsNCqyI4mN5cqeYHrghLUrcnzeDj7dcUC6mA9F3Q6nK/EagclB9UHHTUIB+Pg== X-Received: by 10.37.49.193 with SMTP id x184mr6191867ybx.57.1465058961128; Sat, 04 Jun 2016 09:49:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.230.76 with HTTP; Sat, 4 Jun 2016 09:48:41 -0700 (PDT) In-Reply-To: <57530011.50905@gmail.com> References: <57530011.50905@gmail.com> From: Eric Rescorla Date: Sat, 4 Jun 2016 09:48:41 -0700 Message-ID: To: Yaron Sheffer Content-Type: multipart/alternative; boundary=001a1148af18f468080534769e98 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR #493: Multiple concurrent tickets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2016 16:49:24 -0000 --001a1148af18f468080534769e98 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 4, 2016 at 9:21 AM, Yaron Sheffer wrote: > Hi EKR, > > This is confusing: on the one hand you encourage clients to use multiple > tickets when available, "to the extent possible use a different one for > each new connection", and on the other hand you say that a simple way to > follow the Generation policy is to keep only the latest ticket, and then > presumably to use it multiple times. > What I'm trying to make clear is that clients which don't open multiple concurrent connections don't need to do anything fancy, but that clients which do, should. Can you please expand on the motivation here? Do we assume that a browser > normally opens (say) 5 connections concurrently and we want each one to use > fresh/separate key material? It's not separate keying material. This is a question of linkability between the connections. > If so, maybe the client should indicate how much concurrency it plans to > use? > Yes, we could do that I think we would all be happier if the security proofs hold even if clients > use the same ticket again and again. > To the best of my knowledge, the proofs already assume this, but perhaps Thyla, Sam, or Cas, can weigh in. -Ekr > Thanks, > Yaron > > > On 04/06/16 18:51, Eric Rescorla wrote: > >> https://github.com/tlswg/tls13-spec/pull/493 >> >> Currently the server can send multiple tickets but we don't say anything >> about the semantics. >> So, say a server sends tickets T_1, T_2, T_3... T_n, and the client >> wants to initiate m < n connections, should he use: >> >> - only T_n >> - T_1...T_m >> - T_n, T_n-1, ... T_n-m+1 >> >> The intuition I have had is that we want the third option (latest wins, >> but allow multiples for linkability) but the spec doesn't say and there >> aren't any semantics that tell you, so I think we want some way for the >> server to say "these group of tickets are all co-valid". >> >> I've just created PR#493, which provides an explicit mechanism for this, >> "ticket generations". Tickets with the same generation M are co-valid >> and a ticket with generation N expires all tickets with generation M < >> N. The nice thing about this encoding is that a client can implement the >> old "one ticket at a time" behavior by just ignoring the generation and >> taking the last ticket. >> >> I wanted to call out to cryptographers/analysts that this formalizes the >> existing practice (going back to RFC 5077) of having multiple ticket >> values tied to the same basic secret (though less so with 1.3 because >> tickets issued on connection N+1 don't have the same RMS as those on >> connection N). If there is a problem with this, that would be good to >> know. >> >> Barring major objections, I'll merge this Thursday. >> >> >> -Ekr >> >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> --001a1148af18f468080534769e98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jun 4, 2016 at 9:21 AM, Yaron Sheffer <yaronf.ietf@gmail.c= om> wrote:
Hi EKR,

This is confusing: on the one hand you encourage clients to use multiple ti= ckets when available, "to the extent possible use a different one for = each new connection", and on the other hand you say that a simple way = to follow the Generation policy is to keep only the latest ticket, and then= presumably to use it multiple times.

W= hat I'm trying to make clear is that clients which don't open multi= ple concurrent connections don't need to do anything fancy, but that cl= ients which do, should.


Can you please expand on the motivation here? Do we assu= me that a browser normally opens (say) 5 connections concurrently and we wa= nt each one to use fresh/separate key material?

It's not separate keying material. This is a question of linkabil= ity between the connections.

=C2=A0
If so, maybe the client should indicate how much conc= urrency it plans to use?

Yes, we could = do that


I think we would all be happier if the security proofs hold even if clients= use the same ticket again and again.

T= o the best of my knowledge, the proofs already assume this, but perhaps Thy= la, Sam, or Cas, can weigh in.

-Ekr

=
=C2=A0
Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron


On 04/06/16 18:51, Eric Rescorla wrote:
https://github.com/tlswg/tls13-spec/pull/493

Currently the server can send multiple tickets but we don't say anythin= g
about the semantics.
So, say a server sends tickets T_1, T_2, T_3... T_n, and the client
wants to initiate m < n connections, should he use:

- only T_n
- T_1...T_m
- T_n, T_n-1, ... T_n-m+1

The intuition I have had is that we want the third option (latest wins,
but allow multiples for linkability) but the spec doesn't say and there=
aren't any semantics that tell you, so I think we want some way for the=
server to say "these group of tickets are all co-valid".

I've just created PR#493, which provides an explicit mechanism for this= ,
"ticket generations". Tickets with the same generation M are co-v= alid
and a ticket with generation N expires all tickets with generation M < N. The nice thing about this encoding is that a client can implement the old "one ticket at a time" behavior by just ignoring the generati= on and
taking the last ticket.

I wanted to call out to cryptographers/analysts that this formalizes the existing practice (going back to RFC 5077) of having multiple ticket
values tied to the same basic secret (though less so with 1.3 because
tickets issued on connection N+1 don't have the same RMS as those on connection N). If there is a problem with this, that would be good to know.=

Barring major objections, I'll merge this Thursday.


-Ekr




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


--001a1148af18f468080534769e98-- From nobody Sat Jun 4 10:06:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9859012D5B3 for ; Sat, 4 Jun 2016 10:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOp8ZOfYCFbB for ; Sat, 4 Jun 2016 10:06:54 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 236E712D59C for ; Sat, 4 Jun 2016 10:06:50 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id i65so6960003ith.1 for ; Sat, 04 Jun 2016 10:06:50 -0700 (PDT) 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; bh=IY5RC2EV1JsKA0JNG9OFn7Gr0059nVirrkLTxl7jEUg=; b=mw4h35lcYI/IuER8tj3BmLwmK7kIHrx9DHpQt6angL0mX21owDyBjMsfmEfHssdNHb blFZAevy/a+amh9DOQHD70Tri6mrOuZ+PZuUEP0m+Q0RUOtQX7DkulAViy24+5h+kYYs C0u5IKWSuhJ6mw2sROIZODdosbP0Eoa317fLY= 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; bh=IY5RC2EV1JsKA0JNG9OFn7Gr0059nVirrkLTxl7jEUg=; b=RlMbnFdjx9qNGd7bwJP/SaDl9Bq8bGHO3hgVmBZG5W+7uHFwHHkQnENZyTd6YZDmDO HLJs26URdSh8jwJ3RbFtGiW/tTF4pH/WRHyZl0Z9IK2qxHMfIpA/m+BLduRL3rXGAw9N dHzOuab/LMY9Dsap75r9RZLVO574vmbzTHCfSnz8bqBFiP3ZPQhIuyL06v5bUfQsSb8i jh1rM8RmV8pqcL70F2R+wPBji3wIW0cacD57mnU/gwFw+eCmZW0IE630Srrgrs/wxu05 tbeGyoyuaks36xNah0qRmXI4a9XECRND9h9bNtthCQd4hKSQkmuue8qT3QLYRRZ9o2yR +sYg== X-Gm-Message-State: ALyK8tLWk25dRSdmB7Fn5IUM/CD30Mr0CUrZMNbUemZaPdpfdgLG+g9iZWVKzdpm53t7FermSUq8Z/p0Qg/ggUfD X-Received: by 10.36.227.131 with SMTP id d125mr7214942ith.18.1465060009209; Sat, 04 Jun 2016 10:06:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Sat, 04 Jun 2016 17:06:38 +0000 Message-ID: To: Eric Rescorla , "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1116206ccbb0053476ddcf Archived-At: Subject: Re: [TLS] PR #493: Multiple concurrent tickets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2016 17:06:56 -0000 --94eb2c1116206ccbb0053476ddcf Content-Type: text/plain; charset=UTF-8 I'm not sure I follow why the additional "generation" machinery is necessary. What do we gain from having the server to tell us to discard a ticket beyond what the ticket lifetime already gives? This doesn't seem an effective way to discard key material since, unlike the ticket lifetime, we need a live connection to the server at the time. Beyond that, if a client uses a ticket the server no longer likes, we'll just fall back to a full handshake. That seems fine. I would favor simply saying the client SHOULD prefer to use more recent tickets over earlier ones (since that's probably a good idea) and that clients which expect to open multiple concurrent connections SHOULD retain a window of several one-use tickets. We can always add this generation thing back in later as a TicketExtension if we change our minds. Am I missing something? David On Sat, Jun 4, 2016 at 11:52 AM Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/pull/493 > > Currently the server can send multiple tickets but we don't say anything > about the semantics. > So, say a server sends tickets T_1, T_2, T_3... T_n, and the client wants > to initiate m < n connections, should he use: > > - only T_n > - T_1...T_m > - T_n, T_n-1, ... T_n-m+1 > > The intuition I have had is that we want the third option (latest wins, > but allow multiples for linkability) but the spec doesn't say and there > aren't any semantics that tell you, so I think we want some way for the > server to say "these group of tickets are all co-valid". > > I've just created PR#493, which provides an explicit mechanism for this, > "ticket generations". Tickets with the same generation M are co-valid and a > ticket with generation N expires all tickets with generation M < N. The > nice thing about this encoding is that a client can implement the old "one > ticket at a time" behavior by just ignoring the generation and taking the > last ticket. > > I wanted to call out to cryptographers/analysts that this formalizes the > existing practice (going back to RFC 5077) of having multiple ticket values > tied to the same basic secret (though less so with 1.3 because tickets > issued on connection N+1 don't have the same RMS as those on connection N). > If there is a problem with this, that would be good to know. > > Barring major objections, I'll merge this Thursday. > > > -Ekr > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c1116206ccbb0053476ddcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not sure I follow why the additional "generat= ion" machinery is necessary.

<= /span>
What do we gain from havin= g the server to tell us to discard a ticket beyond what the ticket lifetime= already gives? This doesn't seem an effective way to discard key mater= ial since, unlike the ticket lifetime, we need a live connection to the ser= ver at the time. Beyond that, if a client uses a ticket the server no longe= r likes, we'll just fall back to a full handshake. That seems fine.

I would favor simply saying the client SHOULD = prefer to use more recent tickets over earlier ones (since that's proba= bly a good idea) and that clients which expect to open multiple concurrent = connections SHOULD retain a window of several one-use tickets. We can always add this generation thing back in later a= s a TicketExtension if we change our minds.

Am I missing something?
<= div>

=
David


On Sat, Jun= 4, 2016 at 11:52 AM Eric Rescorla <ekr@rtfm.com> wrote:


- only T_n
- T_1...T_m
- T_n, T_n-1, ... T_n-m+1

=
The intuition I have had is that we want the third option (lates= t wins, but allow multiples for linkability) but the spec doesn't say a= nd there aren't any semantics that tell you, so I think we want some wa= y for the server to say "these group of tickets are all co-valid"= .

I've just created PR#493, which provides an = explicit mechanism for this, "ticket generations". Tickets with t= he same generation M are co-valid and a ticket with generation N expires al= l tickets with generation M < N. The nice thing about this encoding is t= hat a client can implement the old "one ticket at a time" behavio= r by just ignoring the generation and taking the last ticket.
I wanted to call out to cryptographers/analysts that this forma= lizes the existing practice (going back to RFC 5077) of having multiple tic= ket values tied to the same basic secret (though less so with 1.3 because t= ickets issued on connection N+1 don't have the same RMS as those on con= nection N). If there is a problem with this, that would be good to know.

Barring major objections, I'll merge th= is Thursday.


-Ekr


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--94eb2c1116206ccbb0053476ddcf-- From nobody Sat Jun 4 10:16:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B68712D52E for ; Sat, 4 Jun 2016 10:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhKroF5Qa8-Y for ; Sat, 4 Jun 2016 10:16:03 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002: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 4B86E12D522 for ; Sat, 4 Jun 2016 10:16:03 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id o16so107400665ywd.2 for ; Sat, 04 Jun 2016 10:16:03 -0700 (PDT) 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; bh=G1A1YgVU7skr3cyC0YaL3HEl0B8GgkIfM4vrZR/WqTw=; b=U3STM2y87WG3GOkvr5BJQpKM4qiu3tQCApOT5yBHHAtLlIdHODDE1v03zcAZu/pYpp /xhrV82HxKQpi44HhEIeelL6nPMiP4NuOPm1tnHyVToyu0lEQjJSD3nFQCWea5as13Kg kREAdo5mSDiFREFd/aBeC1Oo6wm5Bdn/589z8PbLglY51PKxrCBazCfkfuz6/sECDuAj HKynLUWgG8EN80IOfHWnXl0eI8f20qZRurw34fFVGPGf4G/kqvQwIcUwwgaE9Oq7j2qz qXM3uEh0Dp9+pdg76YsLuJbbG0AoWAmB0Wh2hK8dcQJcx8sKSsSFqRuzrBOIniXXU1+s AQuQ== 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; bh=G1A1YgVU7skr3cyC0YaL3HEl0B8GgkIfM4vrZR/WqTw=; b=ktkolL7HbdfR/ajkzGD+DzrcyfHlED19TVXkqrCGnaxdvzNf1X2OcjcIAbjwRVi9Ah ViTnVLGXyo/ijsxfYMdIjXLpuQcCq/FyfWP1GmtIJ3VMOjBoQmgvfKiptY9uMBcY1rcx o5ipPbezxEtFwNd5RkfwKi58SW9EYueJhzUDV+wmtMXjw1UMNl0sOOhnRy7iOeMGcL49 2qoKyImHJkbqM5KJR7ZT7gamHh1EqImyTuCxEhPLJAORRjYt22fqpUzyS1YUjFqzCHBZ HNwgE3/9RgYwInhSZMeREVaOcxL2YdmvbcqFj3uYNOqgXBmhqqGqWkjP3URCo0fGh3t+ 5xTA== X-Gm-Message-State: ALyK8tJZm+mnQ0CH7cnJBxqrO0iYvUDb8AmYrRICiKs2TXvQiitsTk/Ty7ckwmOmVOZZuKZqdpaLX98+cmprbg== X-Received: by 10.129.51.148 with SMTP id z142mr6297107ywz.322.1465060562563; Sat, 04 Jun 2016 10:16:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.230.76 with HTTP; Sat, 4 Jun 2016 10:15:23 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sat, 4 Jun 2016 10:15:23 -0700 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a11422568682331053476fece Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR #493: Multiple concurrent tickets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2016 17:16:05 -0000 --001a11422568682331053476fece Content-Type: text/plain; charset=UTF-8 I don't think it's principally about discarding keying material, but rather about allowing the server to attach state to a ticket and then have predictable behavior. Consider the obvious case of post-handshake client auth (which I know you hate) and a client which has tickets issue before and after the auth event. If it tries to use them both, that's going to be annoying (though I agree, not fatal). Anyway, I could live without doing this now (part of why I added ticket extensions is to let us make these decisions later), if nobody else thinks it's that valuable. I *do* think it's important that we make sure that analysis supports multiple tickets pointing to the same underlying RMS. -Ekr On Sat, Jun 4, 2016 at 10:06 AM, David Benjamin wrote: > I'm not sure I follow why the additional "generation" machinery is > necessary. > > What do we gain from having the server to tell us to discard a ticket > beyond what the ticket lifetime already gives? This doesn't seem an > effective way to discard key material since, unlike the ticket lifetime, we > need a live connection to the server at the time. Beyond that, if a client > uses a ticket the server no longer likes, we'll just fall back to a full > handshake. That seems fine. > > I would favor simply saying the client SHOULD prefer to use more recent > tickets over earlier ones (since that's probably a good idea) and that > clients which expect to open multiple concurrent connections SHOULD retain > a window of several one-use tickets. We can always add this generation > thing back in later as a TicketExtension if we change our minds. > > Am I missing something? > > David > > > On Sat, Jun 4, 2016 at 11:52 AM Eric Rescorla wrote: > >> https://github.com/tlswg/tls13-spec/pull/493 >> >> Currently the server can send multiple tickets but we don't say anything >> about the semantics. >> So, say a server sends tickets T_1, T_2, T_3... T_n, and the client wants >> to initiate m < n connections, should he use: >> >> - only T_n >> - T_1...T_m >> - T_n, T_n-1, ... T_n-m+1 >> >> The intuition I have had is that we want the third option (latest wins, >> but allow multiples for linkability) but the spec doesn't say and there >> aren't any semantics that tell you, so I think we want some way for the >> server to say "these group of tickets are all co-valid". >> >> I've just created PR#493, which provides an explicit mechanism for this, >> "ticket generations". Tickets with the same generation M are co-valid and a >> ticket with generation N expires all tickets with generation M < N. The >> nice thing about this encoding is that a client can implement the old "one >> ticket at a time" behavior by just ignoring the generation and taking the >> last ticket. >> >> I wanted to call out to cryptographers/analysts that this formalizes the >> existing practice (going back to RFC 5077) of having multiple ticket values >> tied to the same basic secret (though less so with 1.3 because tickets >> issued on connection N+1 don't have the same RMS as those on connection N). >> If there is a problem with this, that would be good to know. >> >> Barring major objections, I'll merge this Thursday. >> >> >> -Ekr >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --001a11422568682331053476fece Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think it's prin= cipally about discarding keying material, but rather about allowing the ser= ver to attach state to a ticket and then have predictable behavior. Conside= r the obvious case of post-handshake client auth (which I know you hate) an= d a client which has tickets issue before and after the auth event. If it t= ries to use them both, that's going to be annoying (though I agree, not= fatal).

Anyway, I could live without doing this now (part of why I added ticket = extensions is to let us make these decisions later), if nobody else thinks = it's that valuable. I *do* think it's important that we make sure t= hat analysis supports multiple tickets pointing to the same underlying RMS.=

-Ekr<= /div>

On Sat, Jun = 4, 2016 at 10:06 AM, David Benjamin <davidben@chromium.org> wrote:
I'm not s= ure I follow why the additional "generation" machinery is necessa= ry.

What do we gain from having the server to tell us to d= iscard a ticket beyond what the ticket lifetime already gives? This doesn&#= 39;t seem an effective way to discard key material since, unlike the ticket= lifetime, we need a live connection to the server at the time. Beyond that= , if a client uses a ticket the server no longer likes, we'll just fall= back to a full handshake. That seems fine.

I would favor simply saying the client SHOULD prefer to use more recent ti= ckets over earlier ones (since that's probably a good idea) and that cl= ients which expect to open multiple concurrent connections SHOULD retain a = window of several one-use tickets. We can a= lways add this generation thing back in later as a TicketExtension if we ch= ange our minds.

<= /span>
Am I missing something?

=
David

On Sat, Jun 4, 2= 016 at 11:52 AM Eric Rescorla <ekr@rtfm.com> wrote:

Currently the server can send = multiple tickets but we don't say anything about the semantics.
So, say a server sends tickets T_1, T_2, T_3... T_n, and the client = wants to initiate m < n connections, should he use:

=
- only T_n
- T_1...T_m
- T_n, T_n-1, ... T_n-m= +1

The intuition I have had is that we want the th= ird option (latest wins, but allow multiples for linkability) but the spec = doesn't say and there aren't any semantics that tell you, so I thin= k we want some way for the server to say "these group of tickets are a= ll co-valid".

I've just created PR#493, w= hich provides an explicit mechanism for this, "ticket generations"= ;. Tickets with the same generation M are co-valid and a ticket with genera= tion N expires all tickets with generation M < N. The nice thing about t= his encoding is that a client can implement the old "one ticket at a t= ime" behavior by just ignoring the generation and taking the last tick= et.

I wanted to call out to cryptographers/analyst= s that this formalizes the existing practice (going back to RFC 5077) of ha= ving multiple ticket values tied to the same basic secret (though less so w= ith 1.3 because tickets issued on connection N+1 don't have the same RM= S as those on connection N). If there is a problem with this, that would be= good to know.

Barring major objections, = I'll merge this Thursday.


=
-Ekr


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

--001a11422568682331053476fece-- From nobody Sat Jun 4 10:23:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B08E12D52E for ; Sat, 4 Jun 2016 10:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOcwsxIxag_5 for ; Sat, 4 Jun 2016 10:23:16 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F013912D0BB for ; Sat, 4 Jun 2016 10:23:15 -0700 (PDT) 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: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 4DC5B2CA42; Sat, 4 Jun 2016 10:23:15 -0700 (PDT) From: "Jim Schaad" To: "'Eric Rescorla'" , References: In-Reply-To: Date: Sat, 4 Jun 2016 10:23:14 -0700 Message-ID: <001e01d1be85$c72a21d0$557e6570$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01D1BE4B.1ACCA960" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKepLaZ/vuU61WRgcf4yhfWJQHKR54/wYyA Content-Language: en-us Archived-At: Subject: Re: [TLS] PR #493: Multiple concurrent tickets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2016 17:23:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001F_01D1BE4B.1ACCA960 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What about the choice of, randomly use any of the tickets but = don=E2=80=99t re-use a ticket? I am not sure why using them in a = specific order is better or worse. Even if you assign a specific ticket = to a reconnect, I would expect that timing of issues might make the = server see the tickets out of order so that it needs to deal with the = fact that they come in randomly.=20 =20 Jim =20 =20 From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Saturday, June 04, 2016 8:51 AM To: tls@ietf.org Subject: [TLS] PR #493: Multiple concurrent tickets =20 https://github.com/tlswg/tls13-spec/pull/493 =20 Currently the server can send multiple tickets but we don't say anything = about the semantics. So, say a server sends tickets T_1, T_2, T_3... T_n, and the client = wants to initiate m < n connections, should he use: =20 - only T_n - T_1...T_m - T_n, T_n-1, ... T_n-m+1 =20 The intuition I have had is that we want the third option (latest wins, = but allow multiples for linkability) but the spec doesn't say and there = aren't any semantics that tell you, so I think we want some way for the = server to say "these group of tickets are all co-valid". =20 I've just created PR#493, which provides an explicit mechanism for this, = "ticket generations". Tickets with the same generation M are co-valid = and a ticket with generation N expires all tickets with generation M < = N. The nice thing about this encoding is that a client can implement the = old "one ticket at a time" behavior by just ignoring the generation and = taking the last ticket. =20 I wanted to call out to cryptographers/analysts that this formalizes the = existing practice (going back to RFC 5077) of having multiple ticket = values tied to the same basic secret (though less so with 1.3 because = tickets issued on connection N+1 don't have the same RMS as those on = connection N). If there is a problem with this, that would be good to = know. =20 Barring major objections, I'll merge this Thursday. =20 =20 -Ekr =20 =20 ------=_NextPart_000_001F_01D1BE4B.1ACCA960 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

What about = the choice of, randomly use any of the tickets but don=E2=80=99t re-use = a ticket?=C2=A0 I am not sure why using them in a specific order is = better or worse.=C2=A0 Even if you assign a specific ticket to a = reconnect, I would expect that timing of issues might make the server = see the tickets out of order so that it needs to deal with the fact that = they come in randomly.

 

Jim

 

 

From:<= /b> = TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric = Rescorla
Sent: Saturday, June 04, 2016 8:51 AM
To: = tls@ietf.org
Subject: [TLS] PR #493: Multiple concurrent = tickets

 

 

Currently the server can send multiple tickets but we = don't say anything about the semantics.

So, say a server sends tickets T_1, T_2, T_3... T_n, = and the client wants to initiate m < n connections, should he = use:

 

- = only T_n

- = T_1...T_m

- T_n, T_n-1, = ... T_n-m+1

 

The intuition I have had is that we want the third = option (latest wins, but allow multiples for linkability) but the spec = doesn't say and there aren't any semantics that tell you, so I think we = want some way for the server to say "these group of tickets are all = co-valid".

 

I've just created PR#493, which provides an explicit = mechanism for this, "ticket generations". Tickets with the = same generation M are co-valid and a ticket with generation N expires = all tickets with generation M < N. The nice thing about this encoding = is that a client can implement the old "one ticket at a time" = behavior by just ignoring the generation and taking the last = ticket.

 

I = wanted to call out to cryptographers/analysts that this formalizes the = existing practice (going back to RFC 5077) of having multiple ticket = values tied to the same basic secret (though less so with 1.3 because = tickets issued on connection N+1 don't have the same RMS as those on = connection N). If there is a problem with this, that would be good to = know.

 

Barring major objections, I'll merge this = Thursday.

 

 

-Ekr

 

 

------=_NextPart_000_001F_01D1BE4B.1ACCA960-- From nobody Sat Jun 4 11:10:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCD912D51F for ; Sat, 4 Jun 2016 11:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOk9O15RI-yk for ; Sat, 4 Jun 2016 11:10:21 -0700 (PDT) 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 C609512D595 for ; Sat, 4 Jun 2016 11:10:20 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id p194so109236397iod.1 for ; Sat, 04 Jun 2016 11:10:20 -0700 (PDT) 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 :cc; bh=YeAFJ//lGLbF+orcdsqqZeUrYHRXNq3lZceNpw4s5o4=; b=IHkEMiA7CtoJ4TUJO2F/yGB5uG5N+IGm/5jq8A9+liHQNDRpbShK7VZVfxV41OEUjj kcvwTXBeueLLeijMF7rO20BXQFY+oCivR4bTZakKLGHRrHSpP0U1sfHqkK9sE+bUoqkw h0LAP0RlAmvzy5uhiBLkC2obKXj+mmS/aIXYQ= 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:cc; bh=YeAFJ//lGLbF+orcdsqqZeUrYHRXNq3lZceNpw4s5o4=; b=V8R2UmJEvRR6sY0keqVJqrEMYiR6l1YSm7pL05QuM3JfZD3N0hD0DZoggBTciDeSa9 OJ9VPlLH07xSVrriKD90y7dV1nsWIqpZaJebvbRWM9UKdKtL0Hj7hOcS+1O6sRrBeR7+ QfDSOxuyNJ9x6IhbOVc8qYdWPCKw1NmbyQY8L8QdXLyKQEIAkwekYer9Yw2/SWveRVLT NRyTYUA4e5N2zdD277SpaYxvFDAiRkr/ERsrGtl5e8aTjIv6sgZB82GAXV5/X6bgLdMg nxT1pvXPmAqsdUY2Lavw8aiSHugVONfFGoAL7/E1B0cQpqZR0ahCf5BPA0tRXZ/CS7U0 nnxA== X-Gm-Message-State: ALyK8tKgrwEvF+Zzha2KWtlFZg/70UDJ4MZg5dA+7ywUNwBkBj1CwucMp+tr0ko9M1C224JS0zqmF2bxmsgN/AEK X-Received: by 10.107.52.16 with SMTP id b16mr13329958ioa.6.1465063819843; Sat, 04 Jun 2016 11:10:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Sat, 04 Jun 2016 18:10:09 +0000 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1144180e8e919f053477c06b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR #493: Multiple concurrent tickets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2016 18:10:24 -0000 --001a1144180e8e919f053477c06b Content-Type: text/plain; charset=UTF-8 Wouldn't the server be required to handle such a case anyway? If it's doing post-handshake auth, it wants to do something reactive, such as based on HTTP request or so. But that means I may have not hit an auth'd URL, saved the session, resumed it, and then hit an auth'd URL. Or perhaps I have two connections, one of which happens to hit auth'd URLs and the other happens to hit unauth'd URLs. There's no ordering between the two sets of sessions, so the unauth'd one may win. That means servers must already allow for resuming an unauth'd session, hitting a auth'd URL, and sending a fresh post-handshake CertificateRequest. If anything, I wouldn't want to encourage servers to assume they can make assumptions here. (I have seen some sites make strong assumptions of this sort, and they've been sufficiently strong that they're unsupportable. It's basically incompatible with having any parallel connections at all.) Incidentally, Chrome will never offer or store sessions on renegotiation, the exact opposite here, and no one seems to have noticed. David On Sat, Jun 4, 2016 at 1:16 PM Eric Rescorla wrote: > I don't think it's principally about discarding keying material, but > rather about allowing the server to attach state to a ticket and then have > predictable behavior. Consider the obvious case of post-handshake client > auth (which I know you hate) and a client which has tickets issue before > and after the auth event. If it tries to use them both, that's going to be > annoying (though I agree, not fatal). > > Anyway, I could live without doing this now (part of why I added ticket > extensions is to let us make these decisions later), if nobody else thinks > it's that valuable. I *do* think it's important that we make sure that > analysis supports multiple tickets pointing to the same underlying RMS. > > -Ekr > > On Sat, Jun 4, 2016 at 10:06 AM, David Benjamin > wrote: > >> I'm not sure I follow why the additional "generation" machinery is >> necessary. >> >> What do we gain from having the server to tell us to discard a ticket >> beyond what the ticket lifetime already gives? This doesn't seem an >> effective way to discard key material since, unlike the ticket lifetime, we >> need a live connection to the server at the time. Beyond that, if a client >> uses a ticket the server no longer likes, we'll just fall back to a full >> handshake. That seems fine. >> >> I would favor simply saying the client SHOULD prefer to use more recent >> tickets over earlier ones (since that's probably a good idea) and that >> clients which expect to open multiple concurrent connections SHOULD retain >> a window of several one-use tickets. We can always add this generation >> thing back in later as a TicketExtension if we change our minds. >> >> Am I missing something? >> >> David >> >> >> On Sat, Jun 4, 2016 at 11:52 AM Eric Rescorla wrote: >> >>> https://github.com/tlswg/tls13-spec/pull/493 >>> >>> Currently the server can send multiple tickets but we don't say anything >>> about the semantics. >>> So, say a server sends tickets T_1, T_2, T_3... T_n, and the client >>> wants to initiate m < n connections, should he use: >>> >>> - only T_n >>> - T_1...T_m >>> - T_n, T_n-1, ... T_n-m+1 >>> >>> The intuition I have had is that we want the third option (latest wins, >>> but allow multiples for linkability) but the spec doesn't say and there >>> aren't any semantics that tell you, so I think we want some way for the >>> server to say "these group of tickets are all co-valid". >>> >>> I've just created PR#493, which provides an explicit mechanism for this, >>> "ticket generations". Tickets with the same generation M are co-valid and a >>> ticket with generation N expires all tickets with generation M < N. The >>> nice thing about this encoding is that a client can implement the old "one >>> ticket at a time" behavior by just ignoring the generation and taking the >>> last ticket. >>> >>> I wanted to call out to cryptographers/analysts that this formalizes the >>> existing practice (going back to RFC 5077) of having multiple ticket values >>> tied to the same basic secret (though less so with 1.3 because tickets >>> issued on connection N+1 don't have the same RMS as those on connection N). >>> If there is a problem with this, that would be good to know. >>> >>> Barring major objections, I'll merge this Thursday. >>> >>> >>> -Ekr >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> > --001a1144180e8e919f053477c06b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wouldn't the server be required to handle such a case = anyway? If it's doing post-handshake auth, it wants to do something rea= ctive, such as based on HTTP request or so. But that means I may have not h= it an auth'd URL, saved the session, resumed it, and then hit an auth&#= 39;d URL. Or perhaps I have two connections, one of which happens to hit au= th'd URLs and the other happens to hit unauth'd URLs. There's n= o ordering between the two sets of sessions, so the unauth'd one may wi= n.

That means servers must already allow for resuming an= unauth'd session, hitting a auth'd URL, and sending a fresh post-h= andshake CertificateRequest. If anything, I wouldn't want to encourage = servers to assume they can make assumptions here. (I have seen some sites make strong assumptions of this sort, and th= ey've been sufficiently strong that they're unsupportable. It's= basically incompatible with having any parallel connections at all.)

Incidentally, Chrome will never offer or store sessions on renego= tiation, the exact opposite here, and no one seems to have noticed.

David
<= /div>


On Sat, Jun 4, 2016 at 1:16 PM Eric Rescorla <ekr@rtfm.com> wrote:
I don= 't think it's principally about discarding keying material, but rat= her about allowing the server to attach state to a ticket and then have pre= dictable behavior. Consider the obvious case of post-handshake client auth = (which I know you hate) and a client which has tickets issue before and aft= er the auth event. If it tries to use them both, that's going to be ann= oying (though I agree, not fatal).

Anyway, I could live without doing this now (p= art of why I added ticket extensions is to let us make these decisions late= r), if nobody else thinks it's that valuable. I *do* think it's imp= ortant that we make sure that analysis supports multiple tickets pointing t= o the same underlying RMS.

-Ekr

On Sat, Jun 4, 2016 at 10:06 AM, David= Benjamin <davidben@chromium.org> wrote:
I'm not sure I follow why the addit= ional "generation" machinery is necessary.

What do= we gain from having the server to tell us to discard a ticket beyond what = the ticket lifetime already gives? This doesn't seem an effective way t= o discard key material since, unlike the ticket lifetime, we need a live co= nnection to the server at the time. Beyond that, if a client uses a ticket = the server no longer likes, we'll just fall back to a full handshake. T= hat seems fine.

I would favor simply saying= the client SHOULD prefer to use more recent tickets over earlier ones (sin= ce that's probably a good idea) and that clients which expect to open m= ultiple concurrent connections SHOULD retain a window of several one-use ti= ckets. We can always add this generation th= ing back in later as a TicketExtension if we change our minds.
=

Am I missin= g something?

David
=


On Sat, Jun 4, 2016 at 11:52 AM Eric Rescorl= a <ekr@rtfm.com>= ; wrote:
Currently the server can send multiple tickets but we don&= #39;t say anything about the semantics.
So, say a server send= s tickets T_1, T_2, T_3... T_n, and the client wants to initiate m < n c= onnections, should he use:

- only T_n
- = T_1...T_m
- T_n, T_n-1, ... T_n-m+1

= The intuition I have had is that we want the third option (latest wins, but= allow multiples for linkability) but the spec doesn't say and there ar= en't any semantics that tell you, so I think we want some way for the s= erver to say "these group of tickets are all co-valid".

I've just created PR#493, which provides an explicit me= chanism for this, "ticket generations". Tickets with the same gen= eration M are co-valid and a ticket with generation N expires all tickets w= ith generation M < N. The nice thing about this encoding is that a clien= t can implement the old "one ticket at a time" behavior by just i= gnoring the generation and taking the last ticket.

I wanted to call out to cryptographers/analysts that this formalizes the e= xisting practice (going back to RFC 5077) of having multiple ticket values = tied to the same basic secret (though less so with 1.3 because tickets issu= ed on connection N+1 don't have the same RMS as those on connection N).= If there is a problem with this, that would be good to know.

Barring major objections, I'll merge this Thursday= .


-Ekr


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

--001a1144180e8e919f053477c06b-- From nobody Sat Jun 4 11:29:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3575612D595 for ; Sat, 4 Jun 2016 11:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qC8l4ggMN8D for ; Sat, 4 Jun 2016 11:29:22 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 13D9B12D0B6 for ; Sat, 4 Jun 2016 11:29:22 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id x189so108289602ywe.3 for ; Sat, 04 Jun 2016 11:29:22 -0700 (PDT) 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; bh=B0L+Qn0YTjSYV+877kcMSVSzdcgKqfC5jWaHUZzfZsk=; b=kzus9e0iGW3WMCUhJiPHidQDtY8uk7mtfVqMUYUILs8OnsFKEanfdW3+mzyhjRj/1C RlbaYd8DWz1/VM4zrVU+zSqSxnogE+Q5kX/t+QkWkL6EqseMeAnIU3kUnaoGZ7ycNzK+ xjgjUOorn5DkmnC9tPxgdo9wc4bkKijy/rCBanILgdaOulXf0uztRo2wrmOxw3EA4Kln 2ihXlOK8TauNI/O51VZ9d9Fv5wq6NtiTXhVWmmPW7nCzQoVpdr2UkROZCzELUhOydU1O hLvQrTxhE1+EE1N2oua3z1iAfhjTRsfvQLjMiqnbQtZJMMVuz5a8zClhdKCzZklC0BGS DvtQ== 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; bh=B0L+Qn0YTjSYV+877kcMSVSzdcgKqfC5jWaHUZzfZsk=; b=R30GPjc3Z52/PHZjoAeZXK2O3vvOCFekPzIq97YDgzaIELntUGhKeU8TnLE3+58j2g 5058rINFsZYQ8BhjsOavUjMM2WaJZTVEcWaA+AweP6oeUjEfbl17GerGcbaxdhYT0YdA rg/wigqs1T+SNI5DvS7jxdqI8IviYKof/i3BZgu4NiJ8AVH/3xbPsKlTibs+KBIDx/sD bY4QzYva6E42YLU0fwWNw8wu3JK4lIkf4rXJnBc7IZcQUMtuOjxa52KTv2kLsoRN4W5k OVlGiKqghT8zmq2ODc0ndlf+3tVi5W80YUe5tUqPjxMz88wLJXoABdpFqvapdOoqILLz xohw== X-Gm-Message-State: ALyK8tJxIFbVhyLac+PS+MBu0ZF7vgTyj5gBCGzC1pWmJqtxxODz6PLpimR+Qu869Ixz7Uxwn9WJLAgaYtycfA== X-Received: by 10.129.164.145 with SMTP id b139mr7124167ywh.171.1465064961224; Sat, 04 Jun 2016 11:29:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.230.76 with HTTP; Sat, 4 Jun 2016 11:28:41 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sat, 4 Jun 2016 11:28:41 -0700 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=94eb2c128ec2965e27053478049a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR #493: Multiple concurrent tickets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2016 18:29:25 -0000 --94eb2c128ec2965e27053478049a Content-Type: text/plain; charset=UTF-8 Yes, these are all reasonable points. It's purely a matter of thinking one might want to minimize the number of anomalies. But maybe that's not a useful goal. -Ekr On Sat, Jun 4, 2016 at 11:10 AM, David Benjamin wrote: > Wouldn't the server be required to handle such a case anyway? If it's > doing post-handshake auth, it wants to do something reactive, such as based > on HTTP request or so. But that means I may have not hit an auth'd URL, > saved the session, resumed it, and then hit an auth'd URL. Or perhaps I > have two connections, one of which happens to hit auth'd URLs and the other > happens to hit unauth'd URLs. There's no ordering between the two sets of > sessions, so the unauth'd one may win. > > That means servers must already allow for resuming an unauth'd session, > hitting a auth'd URL, and sending a fresh post-handshake > CertificateRequest. If anything, I wouldn't want to encourage servers to > assume they can make assumptions here. (I have seen some sites make > strong assumptions of this sort, and they've been sufficiently strong that > they're unsupportable. It's basically incompatible with having any parallel > connections at all.) > > Incidentally, Chrome will never offer or store sessions on renegotiation, > the exact opposite here, and no one seems to have noticed. > > David > > > On Sat, Jun 4, 2016 at 1:16 PM Eric Rescorla wrote: > >> I don't think it's principally about discarding keying material, but >> rather about allowing the server to attach state to a ticket and then have >> predictable behavior. Consider the obvious case of post-handshake client >> auth (which I know you hate) and a client which has tickets issue before >> and after the auth event. If it tries to use them both, that's going to be >> annoying (though I agree, not fatal). >> >> Anyway, I could live without doing this now (part of why I added ticket >> extensions is to let us make these decisions later), if nobody else thinks >> it's that valuable. I *do* think it's important that we make sure that >> analysis supports multiple tickets pointing to the same underlying RMS. >> >> -Ekr >> >> On Sat, Jun 4, 2016 at 10:06 AM, David Benjamin >> wrote: >> >>> I'm not sure I follow why the additional "generation" machinery is >>> necessary. >>> >>> What do we gain from having the server to tell us to discard a ticket >>> beyond what the ticket lifetime already gives? This doesn't seem an >>> effective way to discard key material since, unlike the ticket lifetime, we >>> need a live connection to the server at the time. Beyond that, if a client >>> uses a ticket the server no longer likes, we'll just fall back to a full >>> handshake. That seems fine. >>> >>> I would favor simply saying the client SHOULD prefer to use more recent >>> tickets over earlier ones (since that's probably a good idea) and that >>> clients which expect to open multiple concurrent connections SHOULD retain >>> a window of several one-use tickets. We can always add this generation >>> thing back in later as a TicketExtension if we change our minds. >>> >>> Am I missing something? >>> >>> David >>> >>> >>> On Sat, Jun 4, 2016 at 11:52 AM Eric Rescorla wrote: >>> >>>> https://github.com/tlswg/tls13-spec/pull/493 >>>> >>>> Currently the server can send multiple tickets but we don't say >>>> anything about the semantics. >>>> So, say a server sends tickets T_1, T_2, T_3... T_n, and the client >>>> wants to initiate m < n connections, should he use: >>>> >>>> - only T_n >>>> - T_1...T_m >>>> - T_n, T_n-1, ... T_n-m+1 >>>> >>>> The intuition I have had is that we want the third option (latest wins, >>>> but allow multiples for linkability) but the spec doesn't say and there >>>> aren't any semantics that tell you, so I think we want some way for the >>>> server to say "these group of tickets are all co-valid". >>>> >>>> I've just created PR#493, which provides an explicit mechanism for >>>> this, "ticket generations". Tickets with the same generation M are co-valid >>>> and a ticket with generation N expires all tickets with generation M < N. >>>> The nice thing about this encoding is that a client can implement the old >>>> "one ticket at a time" behavior by just ignoring the generation and taking >>>> the last ticket. >>>> >>>> I wanted to call out to cryptographers/analysts that this formalizes >>>> the existing practice (going back to RFC 5077) of having multiple ticket >>>> values tied to the same basic secret (though less so with 1.3 because >>>> tickets issued on connection N+1 don't have the same RMS as those on >>>> connection N). If there is a problem with this, that would be good to know. >>>> >>>> Barring major objections, I'll merge this Thursday. >>>> >>>> >>>> -Ekr >>>> >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>> >> --94eb2c128ec2965e27053478049a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, these are all reasonable points. It's purely a ma= tter of thinking one might want to minimize
the number of anomalies. Bu= t maybe that's not a useful goal.

-Ekr


On Sat= , Jun 4, 2016 at 11:10 AM, David Benjamin <davidben@chromium.org&g= t; wrote:
Wouldn&= #39;t the server be required to handle such a case anyway? If it's doin= g post-handshake auth, it wants to do something reactive, such as based on = HTTP request or so. But that means I may have not hit an auth'd URL, sa= ved the session, resumed it, and then hit an auth'd URL. Or perhaps I h= ave two connections, one of which happens to hit auth'd URLs and the ot= her happens to hit unauth'd URLs. There's no ordering between the t= wo sets of sessions, so the unauth'd one may win.

Th= at means servers must already allow for resuming an unauth'd session, h= itting a auth'd URL, and sending a fresh post-handshake CertificateRequ= est. If anything, I wouldn't want to encourage servers to assume they c= an make assumptions here. (I have seen some= sites make strong assumptions of this sort, and they've been sufficien= tly strong that they're unsupportable. It's basically incompatible = with having any parallel connections at all.)

Incidentally, = Chrome will never offer or store sessions on renegotiation, the exact oppos= ite here, and no one seems to have noticed.

David


On Sat, Jun 4, 2016 = at 1:16 PM Eric Rescorla <ekr@rtfm.com> wrote:
I don't think it's princip= ally about discarding keying material, but rather about allowing the server= to attach state to a ticket and then have predictable behavior. Consider t= he obvious case of post-handshake client auth (which I know you hate) and a= client which has tickets issue before and after the auth event. If it trie= s to use them both, that's going to be annoying (though I agree, not fa= tal).

= Anyway, I could live without doing this now (part of why I added ticket ext= ensions is to let us make these decisions later), if nobody else thinks it&= #39;s that valuable. I *do* think it's important that we make sure that= analysis supports multiple tickets pointing to the same underlying RMS.

-Ekr

On Sat, Jun 4, 2016 at 10:06 AM, David Benjamin &= lt;davidben@chro= mium.org> wrote:
I'm not sure I follow why the additional "generation"= ; machinery is necessary.

What do we gain from having the se= rver to tell us to discard a ticket beyond what the ticket lifetime already= gives? This doesn't seem an effective way to discard key material sinc= e, unlike the ticket lifetime, we need a live connection to the server at t= he time. Beyond that, if a client uses a ticket the server no longer likes,= we'll just fall back to a full handshake. That seems fine.

I would favor simply saying the client SHOULD prefer t= o use more recent tickets over earlier ones (since that's probably a go= od idea) and that clients which expect to open multiple concurrent connecti= ons SHOULD retain a window of several one-use tickets. We can always add this generation thing back in later as a Tick= etExtension if we change our minds.

Am I missing something?

David


On Sat, Jun 4, 2016 at 11:52 AM Eric Rescorla <ekr@rtfm.com> wrote:

Currentl= y the server can send multiple tickets but we don't say anything about = the semantics.
So, say a server sends tickets T_1, T_2, T_3..= . T_n, and the client wants to initiate m < n connections, should he use= :

- only T_n
- T_1...T_m
-= T_n, T_n-1, ... T_n-m+1

The intuition I have had = is that we want the third option (latest wins, but allow multiples for link= ability) but the spec doesn't say and there aren't any semantics th= at tell you, so I think we want some way for the server to say "these = group of tickets are all co-valid".

I've = just created PR#493, which provides an explicit mechanism for this, "t= icket generations". Tickets with the same generation M are co-valid an= d a ticket with generation N expires all tickets with generation M < N. = The nice thing about this encoding is that a client can implement the old &= quot;one ticket at a time" behavior by just ignoring the generation an= d taking the last ticket.

I wanted to call out to = cryptographers/analysts that this formalizes the existing practice (going b= ack to RFC 5077) of having multiple ticket values tied to the same basic se= cret (though less so with 1.3 because tickets issued on connection N+1 don&= #39;t have the same RMS as those on connection N). If there is a problem wi= th this, that would be good to know.

Barr= ing major objections, I'll merge this Thursday.

-Ekr


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


--94eb2c128ec2965e27053478049a-- From nobody Sat Jun 4 11:42:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB28712D5BB for ; Sat, 4 Jun 2016 11:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id steHKP0Fc_Kq for ; Sat, 4 Jun 2016 11:42:30 -0700 (PDT) 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 07CE412D0A7 for ; Sat, 4 Jun 2016 11:42:29 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id j96so16352188qge.0 for ; Sat, 04 Jun 2016 11:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZU+KQ/CuL5IWBK3lBZD2AmIHr+8hUcshmX9Xgr5xaYY=; b=LDXbUd4Yu+BdXG/WVGnvgJo6GlGH+CNHqNAu6alvadYNOBDPrv9iZrhTr5bThfEG1g O3OLr0Fp/FgFwVVmHnf1CrQHe3gNWX0KVvvZC94ZSK/8ccpfaPcvTNpLtJ3I9G0Bkh7m F6r5dm1VWvameCkkNYoLrEo8vn5Gb0yARWHrw= 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; bh=ZU+KQ/CuL5IWBK3lBZD2AmIHr+8hUcshmX9Xgr5xaYY=; b=LHi8w7m9gyzu/JqwoE/n4ZKfqwDMMCWc61tWF7c+UOK8o726UVUtZI4/qxF0PfmLSq F/YvqJKtx1Ic+Jy28NGGo923R9HxMqwY5ig3ZnYk7H6u0zu3MH7FnTZNW1X/jUY0GSn+ sMLF0lQ9Ux0An1I9VuGKUYx/nGRauHTbPf7R7ksGurc1pttxHDIyFnAscGzYi0kK+1jy ze6cOTY/XionpSjI7SRsCz/28cBo4NRyUu7Z9LnMnqhxgqjSNUzCFh9vzeU/TkPRIDmf NREBhiCkM0oTICfJ12QDMTuaV9q/yTI89ZCUG/kUaWy92iKA7HUISaeNp4tibUIJCkvm /2Vg== X-Gm-Message-State: ALyK8tIX7lm3ytReMQnkomthKF54eFbcBDO1qsu2lN++tGM4/ugvS7Nlvprvledj+Iqp2eTEnQLAYTh1Yf6jvg== X-Received: by 10.140.102.52 with SMTP id v49mr8595286qge.27.1465065749044; Sat, 04 Jun 2016 11:42:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.96.130 with HTTP; Sat, 4 Jun 2016 11:42:28 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:c8cf:f1a1:c70a:cfad] In-Reply-To: References: From: Kyle Rose Date: Sat, 4 Jun 2016 14:42:28 -0400 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c168588b75ef053478333a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR #493: Multiple concurrent tickets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2016 18:42:33 -0000 --001a11c168588b75ef053478333a Content-Type: text/plain; charset=UTF-8 On Sat, Jun 4, 2016 at 1:15 PM, Eric Rescorla wrote: > I don't think it's principally about discarding keying material, but > rather about allowing the server to attach state to a ticket and then have > predictable behavior. Consider the obvious case of post-handshake client > auth (which I know you hate) and a client which has tickets issue before > and after the auth event. If it tries to use them both, that's going to be > annoying (though I agree, not fatal). > I have several thoughts: (1) In many cases, the client can handle this unilaterally. Are there examples of this kind of ticket-relevant state change that the client would not be aware of? When the client is aware of a state change (such as client auth negotiation), it can purge any tickets received before the state change. (2) If the ticket isn't encrypted data but is instead just an index into full session state on the server, the ticket might actually still be valid for state changes that occur after the ticket was handed out. I have no idea how common this brand of session caching is likely to be, but I'm guessing "not very". (3) Tickets already allow the server to encode state: the proposal here seems to be about revealing additional ticket semantics to the client. The server could after all encode the generation in the (encrypted) ticket and then use that to reject old tickets: this results in more full handshakes, but it would eliminate weird behavior when clients use old tickets. Correctness seems achievable either way, so I'm not sure a purge mechanism (beyond expiration) is justified by this specific use case in isolation. Are there other uses cases for which server-initiated purge of classes of session tickets would be helpful? Kyle --001a11c168588b75ef053478333a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 4, 2016 at 1:15 PM, Eric Rescorla <ekr@rtfm.com> wrote:
I don't think it's principally about discarding keying material, = but rather about allowing the server to attach state to a ticket and then h= ave predictable behavior. Consider the obvious case of post-handshake clien= t auth (which I know you hate) and a client which has tickets issue before = and after the auth event. If it tries to use them both, that's going to= be annoying (though I agree, not fatal).

=
I have several thoughts:

(1) In many cases, the client ca= n handle this unilaterally. Are there examples of this kind of ticket-relev= ant state change that the client would not be aware of? When the client is = aware of a state change (such as client auth negotiation), it can purge any= tickets received before the state change.

(2) If the tic= ket isn't encrypted data but is instead just an index into full session= state on the server, the ticket might actually still be valid for state ch= anges that occur after the ticket was handed out. I have no idea how common= this brand of session caching is likely to be, but I'm guessing "= not very".

(3) Tickets already allow the server to e= ncode state: the proposal here seems to be about revealing additional ticke= t semantics to the client. The server could after all encode the generation= in the (encrypted) ticket and then use that to reject old tickets: this re= sults in more full handshakes, but it would eliminate weird behavior when c= lients use old tickets.

Correctness seems ach= ievable either way, so I'm not sure a purge mechanism (beyond expiratio= n) is justified by this specific use case in isolation. Are there other use= s cases for which server-initiated purge of classes of session tickets woul= d be helpful?

Kyle

--001a11c168588b75ef053478333a-- From nobody Sat Jun 4 12:05:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F92C12D50D for ; Sat, 4 Jun 2016 12:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnOpt7IUH23H for ; Sat, 4 Jun 2016 12:04:51 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002: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 AD72812D1BD for ; Sat, 4 Jun 2016 12:04:51 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id c127so108638059ywb.1 for ; Sat, 04 Jun 2016 12:04:51 -0700 (PDT) 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; bh=C20CYl9zdUfmdFXt2chQD8NdMmienPfqGYMfPSbZmxw=; b=QEVBflZO6dhU31wm1nHXPK19eEi+pJzsEGczoVylx8TEWmcm8NEqSbaTFvHKCQaWsL 1ONAIQhT2NkMQdAuMElF3qWxu7CA4HXkd9fyFmdz3a7fMyW/eGLfWkRprdOo9gH+cSkn 2qKd+guhbvVk9z0qhuq11gM4SfQu0fBflhx5g5oenDuva5copyyOQqsszdRhRO26UtQB nyLdgU/zsuihjR7TnGopscxXKcdT3vufX/lnM2+PyDXyWcFkcucazQORxSAOSMVPhp0Q n/LUfMzPrJclg5QkNpddVajGaJdBs42htqch9QqlEBJKNaa+gaTLDhpgvo/qQdOmWfG4 txTw== 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; bh=C20CYl9zdUfmdFXt2chQD8NdMmienPfqGYMfPSbZmxw=; b=jsz22T8xO1UPpFzMtOm2kcqFEmchKDGGR5pC+6oNeVG3H+Yk9Gbr1qMpkPDwEkJZcZ I9oYKr8KO4MLg5qWQ4KJcZjLVxMa/W1bqfS0nqtjqtkvxSErRvA+7ovp+pIsuc93xZ9S UcAyU1o+drByuxhwMG771qFwpmMadMBeayu/HPf4hSukJ4heaBDIqpWkk/0heFBZSOEB LEMpduZEdqXle4Ei19iXnVapMAu4yyoANrrrsJs94sjSC7PY+lKbdO0D+QIRGr8KgIDz OWE6rZ9pLOQEcI6ILovD8/VxYv2lHI7DvOdiSPWEqzjodGiNdTt58rbPp8bD8+yki9ru 28PQ== X-Gm-Message-State: ALyK8tLnlnT7Wy/VaF/MMNGFWBuagppO1u7jEzxQUrxhjrecD+BPBKZmMPBr4mcZmd1Rf7GC2n84RhPuKXCKlw== X-Received: by 10.129.160.149 with SMTP id x143mr6512862ywg.180.1465067090956; Sat, 04 Jun 2016 12:04:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.230.76 with HTTP; Sat, 4 Jun 2016 12:04:11 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sat, 4 Jun 2016 12:04:11 -0700 Message-ID: To: Kyle Rose Content-Type: multipart/alternative; boundary=94eb2c07ee0487993f053478835d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR #493: Multiple concurrent tickets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2016 19:04:59 -0000 --94eb2c07ee0487993f053478835d Content-Type: text/plain; charset=UTF-8 On Sat, Jun 4, 2016 at 11:42 AM, Kyle Rose wrote: > On Sat, Jun 4, 2016 at 1:15 PM, Eric Rescorla wrote: > >> I don't think it's principally about discarding keying material, but >> rather about allowing the server to attach state to a ticket and then have >> predictable behavior. Consider the obvious case of post-handshake client >> auth (which I know you hate) and a client which has tickets issue before >> and after the auth event. If it tries to use them both, that's going to be >> annoying (though I agree, not fatal). >> > > I have several thoughts: > > (1) In many cases, the client can handle this unilaterally. Are there > examples of this kind of ticket-relevant state change that the client would > not be aware of? When the client is aware of a state change (such as client > auth negotiation), it can purge any tickets received before the state > change. > Sure. HTTP-level authentication via a Web form. (3) Tickets already allow the server to encode state: the proposal here > seems to be about revealing additional ticket semantics to the client. The > server could after all encode the generation in the (encrypted) ticket and > then use that to reject old tickets: this results in more full handshakes, > but it would eliminate weird behavior when clients use old tickets. > > Correctness seems achievable either way, so I'm not sure a purge mechanism > (beyond expiration) is justified by this specific use case in isolation. > Are there other uses cases for which server-initiated purge of classes of > session tickets would be helpful? > Unexpected key changes. -Ekr > > > Kyle > > --94eb2c07ee0487993f053478835d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jun 4, 2016 at 11:42 AM, Kyle Rose <krose@krose.org> wrote:
On Sat, Jun 4, 2016 at 1:15 PM, Eric Rescorla <ekr@rtfm.com> w= rote:
I don't think it's principally about discarding keying = material, but rather about allowing the server to attach state to a ticket = and then have predictable behavior. Consider the obvious case of post-hands= hake client auth (which I know you hate) and a client which has tickets iss= ue before and after the auth event. If it tries to use them both, that'= s going to be annoying (though I agree, not fatal).

I have several thoughts:

(1) In many cas= es, the client can handle this unilaterally. Are there examples of this kin= d of ticket-relevant state change that the client would not be aware of? Wh= en the client is aware of a state change (such as client auth negotiation),= it can purge any tickets received before the state change.
=

Sure. HTTP-level authenticatio= n via a Web form.


(3) Tickets already allow the server to encode state: the proposa= l here seems to be about revealing additional ticket semantics to the clien= t. The server could after all encode the generation in the (encrypted) tick= et and then use that to reject old tickets: this results in more full hands= hakes, but it would eliminate weird behavior when clients use old tickets. =

Correctness seems achievable either way, so I= 'm not sure a purge mechanism (beyond expiration) is justified by this = specific use case in isolation. Are there other uses cases for which server= -initiated purge of classes of session tickets would be helpful?

Unexpected key changes.
=

-Ekr
=C2=A0
<= div>

Kyle
=

--94eb2c07ee0487993f053478835d-- From nobody Sat Jun 4 12:36:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1232812D5BB for ; Sat, 4 Jun 2016 12:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5E1jpgmYeGl for ; Sat, 4 Jun 2016 12:36:46 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 5F02012D1BD for ; Sat, 4 Jun 2016 12:36:46 -0700 (PDT) Received: by mail-qg0-x22d.google.com with SMTP id p34so26373026qgp.1 for ; Sat, 04 Jun 2016 12:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CHCR+NdZQRN5WVwU26EnjvOgWP+Et5ECPsmVC4xuD8A=; b=fePFl3K0awJ0gd37o4Z+CBGcdpcRt0l/E76Ih4rT1oYKeNwu/4opU1gj+Ft6vPjHvY peScpMYSBU6thYBl/qW2qy2k7/N3hr7BtCPRZNS79dN5tCGugGPLFT67kmURqbVkDFQz 2EIjH/40hrOHgcnMyEgBf9HGhJrO4kZoGoP28= 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; bh=CHCR+NdZQRN5WVwU26EnjvOgWP+Et5ECPsmVC4xuD8A=; b=eDeIb9YbInWSwor8HX3XoMFAcSGbd2WdvnCxTmA9FFNUAv8HM7GJ+TWjrJM+x1hK/5 Yx/VlOIvOksjGp2Sn71J4BW91qL9ZoVnUQ8/DLJ6aahP1Ufteblwx3Fh0s4X29tMOQHl ui4tm4wl8ksBTZnTzfv/GeIWFli1p8kXEXUJYRrlAwVi8omPFjO+J+oG8TOv42EkXIXq LHoFq5NXlSSfWNBVXNHJ9uTfcnCVZPEe8LBaheDDW3HcJl+6wbTgAYCBmk+4GPGaiQGR 5d/N/nkPXGVUmUstDm858dm28e2jbhbj3ewbFYf55m0hT7VkKE4UVHITlEu25xtno5NO 3FQw== X-Gm-Message-State: ALyK8tLM5x6N7yEiyw5bkaUtBDU4fpM4Pa1RykP5mMVS35vBpvL716XgcFVhqE9CEnDPuhzSTXOL+1DkS8DQdA== X-Received: by 10.140.94.165 with SMTP id g34mr2056983qge.81.1465069005470; Sat, 04 Jun 2016 12:36:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.96.130 with HTTP; Sat, 4 Jun 2016 12:36:44 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:c8cf:f1a1:c70a:cfad] In-Reply-To: References: From: Kyle Rose Date: Sat, 4 Jun 2016 15:36:44 -0400 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113a4222a48f19053478f551 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR #493: Multiple concurrent tickets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2016 19:36:48 -0000 --001a113a4222a48f19053478f551 Content-Type: text/plain; charset=UTF-8 > > (1) In many cases, the client can handle this unilaterally. Are there > examples of this kind of ticket-relevant state change that the client would > not be aware of? When the client is aware of a state change (such as client > auth negotiation), it can purge any tickets received before the state > change. > > Sure. HTTP-level authentication via a Web form. > Would that typically feed into the ticket state? I'm thinking of something like Rails, which (at least when I worked with it) maintained its own session state separately from TLS session state, and signaled via cookie or Auth header. > Correctness seems achievable either way, so I'm not sure a purge mechanism >> (beyond expiration) is justified by this specific use case in isolation. >> Are there other uses cases for which server-initiated purge of classes of >> session tickets would be helpful? >> > > Unexpected key changes. > Rotation of the ticket-encrypting key? This seems like a good argument for it, because it's something that's likely to happen regularly, and maybe even on a schedule, and almost certainly across all clients simultaneously (meaning "load spike" if the clients aren't guided to the right behavior). In general, I like the idea of having a way to purge state beyond simply expiration; I wonder if generation is the right level of specificity, or if it's too general and we should reopen the expiration time vs. issue time+TTL discussion and allow purging by issue time. (I'm not actually suggesting the latter.) But I also don't have a strong opinion about the balance between complexity and performance benefit here. Kyle --001a113a4222a48f19053478f551 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(1) In = many cases, the client can handle this unilaterally. Are there examples of = this kind of ticket-relevant state change that the client would not be awar= e of? When the client is aware of a state change (such as client auth negot= iation), it can purge any tickets received before the state change.

=

Sure. HTTP-level authentication via= a Web form.

Would = that typically feed into the ticket state? I'm thinking of something li= ke Rails, which (at least when I worked with it) maintained its own session= state separately from TLS session state, and signaled via cookie or Auth h= eader.
=C2=A0
Correctness seems achievable either way, so I&= #39;m not sure a purge mechanism (beyond expiration) is justified by this s= pecific use case in isolation. Are there other uses cases for which server-= initiated purge of classes of session tickets would be helpful?
=

Unexp= ected key changes.

= Rotation of the ticket-encrypting key? This seems like a good argument for = it, because it's something that's likely to happen regularly, and m= aybe even on a schedule, and almost certainly across all clients simultaneo= usly (meaning "load spike" if the clients aren't guided to th= e right behavior).

In general, I like the idea of having = a way to purge state beyond simply expiration; I wonder if generation is th= e right level of specificity, or if it's too general and we should reop= en the expiration time vs. issue time+TTL discussion and allow purging by i= ssue time. (I'm not actually suggesting the latter.) But I also don'= ;t have a strong opinion about the balance between complexity and performan= ce benefit here.

Kyle

--001a113a4222a48f19053478f551-- From nobody Sat Jun 4 14:46:27 2016 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 7961C12D556; Sat, 4 Jun 2016 14:46:24 -0700 (PDT) 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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160604214624.4297.82314.idtracker@ietfa.amsl.com> Date: Sat, 04 Jun 2016 14:46:24 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-dnssec-chain-extension-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the mailing list 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, 04 Jun 2016 21:46:24 -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 of the IETF. Title : A DANE Record and DNSSEC Authentication Chain Extension for TLS Authors : Melinda Shore Richard Barnes Shumon Huque Willem Toorop Filename : draft-ietf-tls-dnssec-chain-extension-00.txt Pages : 12 Date : 2016-06-04 Abstract: This draft describes a new TLS extension for transport of a DNS record set serialized with the DNSSEC signatures needed to authenticate that record set. The intent of this proposal is to allow TLS clients to perform DANE authentication of a TLS server certificate without needing to perform additional DNS record lookups. It will typically not be used for general DNSSEC validation of TLS endpoint names. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-00 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 Jun 6 02:08:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F40112D672 for ; Mon, 6 Jun 2016 02:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FtqdVBZHci9 for ; Mon, 6 Jun 2016 02:08:45 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (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 6114F12D63E for ; Mon, 6 Jun 2016 02:08:45 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id DAB2F412DD for ; Mon, 6 Jun 2016 11:08:43 +0200 (CEST) To: tls@ietf.org References: From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <57553D9B.3000704@restena.lu> Date: Mon, 6 Jun 2016 11:08:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fORSstsVXDWWJCS10v3DlQvatCFopJFro" Archived-At: Subject: Re: [TLS] Downgrade protection, fallbacks, and server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 06 Jun 2016 09:08:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fORSstsVXDWWJCS10v3DlQvatCFopJFro Content-Type: multipart/mixed; boundary="W0CsCgEgsGFRNuNmKdqImg11xRcQ8EXgW" From: Stefan Winter To: tls@ietf.org Message-ID: <57553D9B.3000704@restena.lu> Subject: Re: Downgrade protection, fallbacks, and server time References: In-Reply-To: --W0CsCgEgsGFRNuNmKdqImg11xRcQ8EXgW Content-Type: multipart/mixed; boundary="------------020408000601010406020907" This is a multi-part message in MIME format. --------------020408000601010406020907 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, > > > > I agree with Hubert. The big question is how you get the bug report to > the server operator. Automated mail to webmaster@domain_of_requested_hostname? Maybe a few thousand new mails in the operator's inbox of sorts "we have encountered a situation where your version intolerance broke things. Fix it." (with all the technical details you can dump on an admin and expect him to understand; which is more than a user can take) wakes them up. That is, for domains still using webmaster@ like they should. Greetings, Stefan Winter > > With servers which are currently maintained, it should be possible, > although difficult in specific instances to contact the owner. With > servers which aren't being maintained, e.g. those in imbedded devices, > the problem becomes much harder. > > If the client has a UI, it could explain the problem to the user and > ask if the user wants to continue with degraded security. If so, then > always use the remembered highest supported version with that server > domain name, with perhaps occasional reminders to the user of the > situation. > > In any case, we should be addressing our efforts to getting bugs > fixed, not just coding around them. > > Cheers - Bill > > -----------------------------------------------------------------------= -- > Bill Frantz | The first thing you need when | Periwinkle > (408)356-8506 | using a perimeter defense is a | 16345 Englewood A= ve > www.pwpconsult.com | perimeter. | Los Gatos, CA 950= 32 > --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------020408000601010406020907 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------020408000601010406020907-- --W0CsCgEgsGFRNuNmKdqImg11xRcQ8EXgW-- --fORSstsVXDWWJCS10v3DlQvatCFopJFro 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 iQIcBAEBCgAGBQJXVT2bAAoJEMDeajWKOdxmx+UQAM9XM3BHzcaDrcIncuzyVFgt V/lIMkPfBzwf7xFtEFZZ9mKNebeYNN7PVWH3BAs45zI/nWyk8B05/6SXrYBQnv6o BqkWrh8l7TD0euQxa6IODB+ZpHX11wrxtAkmNBVvqTxXwkjh1mwG9/6atKghc6JI aJR2Z0d5FP9Z3DgN9/VATraPfL/FTmDQ6X7vN1y5sgCVA/qfBOGtNIpzRFH2Dw/R Wq50TZo8A6ltbuhgqR9F+Lug4YzVJamtOXYbj+5ablyh/AVCgGe+eBVPtX2Npwfo +pHsJZfGgmJtiuyalGhuSbVqda+uhiSHIWij5Si/3wB/KcD5cD9rb5FHt/uEclVd 2o6UQaHA4ctEuqFW+znowrQbEzkrjGU1v+ZrKTB61GI7yNYTsTUl/+fxEKQ2JZX9 Ncwb62FvCM/5e3y+9W+6rI9ng/g6FnqvtI/vCXeP0aoE2AAHlYnJ+31wzLrp5dLA YcmxXSa6gi0sVqTJWJCFHlvU8TS95IRrW9sGafPXBV/d6lNpDC3F4M77hqOwl00e MVS+bTm6Yswzqk3QYRr1SYouRrkVaqVSuh5F4LQ3H4PrdUM29stqqK8y9DYo0oct Ie3oDhv55MHtafa/1LgmamullmzV5wKCnsyb1mtSLhOzsqyDCZVfkTkBHOh0kzOP aH0Hhz8qMU/jLXl/tlvj =+zVT -----END PGP SIGNATURE----- --fORSstsVXDWWJCS10v3DlQvatCFopJFro-- From nobody Mon Jun 6 02:53:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2667312B013 for ; Mon, 6 Jun 2016 02:53:36 -0700 (PDT) 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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=delignat-lavaud.fr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id johRaMe0arxb for ; Mon, 6 Jun 2016 02:53:34 -0700 (PDT) Received: from argon.maxg.info (argon.maxg.info [IPv6:2001:41d0:2:7f22::1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201D312B068 for ; Mon, 6 Jun 2016 02:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=delignat-lavaud.fr; s=dkim; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=w/X6brV1rrADGteFC3TVyPcd/RxTHXcQImwMznU9i1A=; b=cpNv+0RLJg7CK8OjquI+FtF9R3qQQs3sBq9u+aCzoUzfvOYGlPziWO+TbXUEMw2Oz/v2kaNraISYMmPK9Nr2uLV5bftkYRjeUEt1Wfj9BbZT9u1U8ixCc63hC0SZNhN+el863pHzIvoIVU2hl/rP/8srXDIZYc9vxC7r8+UQraCS3ZBpr4FBQjfK6AMtZnnUvt+5ypF9Qg6k5OTS9PxZtjVdJCDXhTWwY/NCCpp25192sFF0fhjW/RQEYRiU9uiuG9/ajFDU5sEQml32ImriwDQFCBYAwxxtHN9tRd+W3wTdKpiDYho/a7EOjT3VYST3SMkTTfWoE5MQXM7EOUVieg==; Received: from localhost (authenticated.user.IP.removed [::1]) by argon.maxg.info with esmtpa (envelope-from ) id 1b9rDv-0007X5-GB ; Mon, 06 Jun 2016 11:53:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 06 Jun 2016 10:53:30 +0100 From: Antoine Delignat-Lavaud To: Eric Rescorla Organization: Microsoft Research In-Reply-To: References: Message-ID: <76cae24df17eb7fc89a9cc1a4b2f341d@maxg.info> X-Sender: antoine@delignat-lavaud.fr User-Agent: Roundcube Webmail/1.0.2 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] PR #493: Multiple concurrent tickets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 06 Jun 2016 09:53:36 -0000 Hi, Le 2016-06-04 16:51, Eric Rescorla a écrit : > I wanted to call out to cryptographers/analysts that this formalizes > the existing practice (going back to RFC 5077) of having multiple > ticket values tied to the same basic secret (though less so with 1.3 > because tickets issued on connection N+1 don't have the same RMS as > those on connection N). If there is a problem with this, that would be > good to know. Looking at the pull request, I don't think it will have much impact on the protocol analysis given that it doesn't introduce any adversarial capability that wasn't already present before. If anything, your change may enable a proof of session unlinkability for well-behaved clients connecting to honest servers, under a number of restrictions. My main complain about the current specification is that it doesn't clearly state that the specified restriction mechanisms for ticket lifetime and usage only partially bound the forward secrecy loss of PSK; implementations themselves must independently keep track of the lifetime of any given PSK in addition to managing the lifetime of tickets and ticket encryption keys by servers. For instance, if a server keeps re-issuing allow_psk_resumption tickets based on the same PSK it is up to the client to expire the session at some point even if still has valid ticket(s). Similarly, if servers do not store PSK lifetime information inside tickets it may end up using an ancient PSK although the ticket may have been encrypted under a recent ticket key. Best, Antoine From nobody Mon Jun 6 03:48:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856B712D6A5 for ; Mon, 6 Jun 2016 03:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.328 X-Spam-Level: X-Spam-Status: No, score=-8.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7PmTylmeFxR for ; Mon, 6 Jun 2016 03:48:23 -0700 (PDT) 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 F3DE912D5A9 for ; Mon, 6 Jun 2016 03:48:22 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5782EC04D28F; Mon, 6 Jun 2016 10:48:22 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-122.brq.redhat.com [10.34.0.122]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u56AmKTQ009046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jun 2016 06:48:22 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 06 Jun 2016 12:48:20 +0200 Message-ID: <1612869.mrh4f7qht5@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.11-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <201606031616.14451.davemgarrett@gmail.com> References: <201606031616.14451.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1726266.PhP440cdS0"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 06 Jun 2016 10:48:22 +0000 (UTC) Archived-At: Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 06 Jun 2016 10:48:24 -0000 --nextPart1726266.PhP440cdS0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 03 June 2016 16:16:13 Dave Garrett wrote: > The idea of using an empty extension as an indicator really isn't > fundamentally different from what I'm suggesting here. We'd just have= > an arbitrary set of new version indicators mixed in with extensions > instead of inside a new generalized basket. My replacement was > (again, it's over a year old) designed to be a general purpose > long-term solution that could handle 1.3, 1.4, draft versions, > experiments, etc, without special-casing. I'm not fundamentally > against just adding a TLS 1.3 version indicator extension and > freezing the old version number to 1.2. It just feels a little more > hacky to me, though in the short-term it's simpler. The reason why we want to add this is because there are programmers tha= t=20 get the normal version negotiation wrong. What makes you think that a new version negotiation that works more or=20= less in the same way will _not_ be implemented incorrectly? Counter example: there are servers which handle TLSv1.2 and do not=20 handle TLSv1.3 (e.g. ebay.com), and there are implementations that do=20= not handle multiple names in SNI extension. Both are supported only by=20= either recent or very recent implementations. And don't forget that what we are proposing here is significantly=20 complicating implementations that most likely _are_ behaving properly=20= and _are_ handling unknown versions/extensions/ciphersuites correctly;=20= just because there are few bad apples. > With respect to the concern of version numbers being moved to a > non-fixed position, we could just require that the new version list > extension be first or last in the extensions list. it's still after the variable-length list of 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 --nextPart1726266.PhP440cdS0 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 iQIcBAABCgAGBQJXVVT0AAoJEJKo0bgB0vX1KPsP/2xdLNHJNOm4ghBEXlSdjdjv EJaTRKtGfDemetGBW5768xZv30v10LcvVP6DKFmVd2XcT5QWTitC47tts3OS7awY 43vQ+HE+cJE738jY/34oCz7q5GSV8ZDOceXI/oRdKB2lBA6pAYV70LBCRLZd0UVg nw2OQhjrKC78Mp81ynaCsDnw8S8D2EF7LgXMT7/xd8JRQ51WQq+r3SaGhFfpBMOE aQN6Pt6+P/7YfdLCETUMuUu+AvP71FRhw0Ed/+owitIfGqIhmYGatq+0I2bPV347 Uzx62jk9pAv+u/TWBnSwlDGBbkklSikypiEc4o5ESFq0icDdqjgz/16TPKRv7iCl qTPZc4TNyhiDj+nq/Ct2rCdqGkwU/ytLER28KNsAqhahqfWUR2kIaUFefjd34Hal qEkqEfoHpkYkFL3a/yFGiZ+M00PjEfd3E1bue2qcUJM5TjeDmZUIVRg0YjTYqSJc uwECOSfVFVA5L7ckuIBGYyIcSmIHnmkOapMeo/YkTf6eXXBpiEAZcPGQHXC87XXM Cmkoxop5qYdDEehJkAykWDecM1DIqpTBcWBeFlAJxnZ6W2diJ74ysAig5OvLNuKr 5BaKYI2+queb1NuZOWCVPawp37qFFC55DP1GiTNqxe6RWVw27FqodLffmIMzsfyG ppTaCT/838Ei/FC9UetL =C4fl -----END PGP SIGNATURE----- --nextPart1726266.PhP440cdS0-- From nobody Mon Jun 6 06:06:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B9B12D781 for ; Mon, 6 Jun 2016 06:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.727 X-Spam-Level: X-Spam-Status: No, score=-3.727 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nln0DOISUNLo for ; Mon, 6 Jun 2016 06:06:16 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEC712D77E for ; Mon, 6 Jun 2016 06:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1465218376; x=1496754376; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=5GrS15pIzrAJLf1+Qy4FNH6yZqWHaYSoSD3K8J96QFo=; b=aRTd4wBkzvKJO+BjoHWEVdNGo6M/h7Fif+OP6AIvMymQ3YAvZSyoww0a wPiQC1Mnqs+RLCBKi3IDzI3FMuIHiZJOC+h8wr0v+mub2BdaOaOTKf6th OYnv2P06Xn5d7Gff0KF9amCO84fp7Ef+JwVRIY6mS3CuJSuGQ/iae7vl5 YeHiI8jCj/YndulIVLlerDw2mQUGciC4FPQppP3SzMlV13x/QHeSDhKNA +DMXUa9PH2cjXb664F/3J32hEksaTL0ZPAacFuN67MzoMuc5PFPtSRCW5 hlHcC6dYH+GNEbo0cX/8INhSb8TgjFIacb+CkiHcj1eiNufeoeAgGmkGw g==; X-IronPort-AV: E=Sophos;i="5.26,427,1459771200"; d="scan'208";a="89940356" 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; 07 Jun 2016 01:05:49 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Tue, 7 Jun 2016 01:05:49 +1200 From: Peter Gutmann To: "" Thread-Topic: Adoption of TLS-LTS Thread-Index: AdG/9CVqy8MYXur6TqWx/88FbT3L7g== Date: Mon, 6 Jun 2016 13:05:49 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C9CA49@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [TLS] Adoption of TLS-LTS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 06 Jun 2016 13:06:19 -0000 TLS-LTS, https://tools.ietf.org/html/draft-gutmann-tls-lts-03, has more or= =0A= less stabilised, incorporating all the feedback I've had for it (there's on= ly=0A= one open question still remaining), so I'd like to request that it now be= =0A= adopted as a WG item.=0A= =0A= I'd also like to request an early/temporary assignment for an extension ID,= to=0A= provide something a bit more usable than the much-overloaded 0x42 that's=0A= currently being used.=0A= =0A= Peter.= From nobody Mon Jun 6 06:11:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488FB12D785 for ; Mon, 6 Jun 2016 06:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNVVKD_LP8u1 for ; Mon, 6 Jun 2016 06:11:28 -0700 (PDT) Received: from lnx500.hrz.tu-darmstadt.de (lnx500.hrz.tu-darmstadt.de [130.83.156.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1480E12D0B0 for ; Mon, 6 Jun 2016 06:11:27 -0700 (PDT) Received: from smtp.tu-darmstadt.de (lnx504.hrz.tu-darmstadt.de [130.83.156.233]) by lnx500.hrz.tu-darmstadt.de (8.14.4/8.14.4/HRZ/PMX) with ESMTP id u56DBPsa011060 for ; Mon, 6 Jun 2016 15:11:25 +0200 (envelope-from guenther@cs.tu-darmstadt.de) Received: from [130.83.73.226] by smtp.tu-darmstadt.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1b9uJR-0001id-7X for tls@ietf.org; Mon, 06 Jun 2016 15:11:25 +0200 References: <76cae24df17eb7fc89a9cc1a4b2f341d@maxg.info> From: =?UTF-8?Q?Felix_G=c3=bcnther?= To: tls@ietf.org Openpgp: id=2BAE4A6F7946461B700161B352AF0200D3F1700E; url=http://www.felixguenther.info/publickey.asc Message-ID: <5755767B.5000502@cs.tu-darmstadt.de> Date: Mon, 6 Jun 2016 15:11:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <76cae24df17eb7fc89a9cc1a4b2f341d@maxg.info> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C6NLL91fkeNfCf7nPrJ1gIUcVjwATFQxO" X-PMX-TU: seen v1.2 by 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2016.6.6.130316 X-PMX-RELAY: outgoing Archived-At: Subject: Re: [TLS] PR #493: Multiple concurrent tickets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 06 Jun 2016 13:11:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --C6NLL91fkeNfCf7nPrJ1gIUcVjwATFQxO Content-Type: multipart/mixed; boundary="SrEblG9vjB5jJjt65C3Fbm4DEooU2b0aW" From: =?UTF-8?Q?Felix_G=c3=bcnther?= To: tls@ietf.org Message-ID: <5755767B.5000502@cs.tu-darmstadt.de> Subject: Re: [TLS] PR #493: Multiple concurrent tickets References: <76cae24df17eb7fc89a9cc1a4b2f341d@maxg.info> In-Reply-To: <76cae24df17eb7fc89a9cc1a4b2f341d@maxg.info> --SrEblG9vjB5jJjt65C3Fbm4DEooU2b0aW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On 06/06/2016 11:53 +0200, Antoine Delignat-lavaud wrote: > Le 2016-06-04 16:51, Eric Rescorla a =C3=A9crit : >> I wanted to call out to cryptographers/analysts that this formalizes >> the existing practice (going back to RFC 5077) of having multiple >> ticket values tied to the same basic secret (though less so with 1.3 >> because tickets issued on connection N+1 don't have the same RMS as >> those on connection N). If there is a problem with this, that would be= >> good to know. >=20 > Looking at the pull request, I don't think it will have much impact on > the protocol analysis given that it doesn't introduce any adversarial > capability that wasn't already present before. If anything, your change= > may enable a proof of session unlinkability for well-behaved clients > connecting to honest servers, under a number of restrictions. I agree with Antoine that I don't expect multiple ticket values for the same cryptographic key to have a (negative) impact on the/our security results. As the ticket value is, through ClientHello, part of the handshake hash, hence flowing into the key derviation, separate ticket values should "domain-separate" the keys established from the same RMS. And yes, might be one can establish some form of cryptographic session/handshake unlinkability for honest client-server communication. Cheers, Felix --SrEblG9vjB5jJjt65C3Fbm4DEooU2b0aW-- --C6NLL91fkeNfCf7nPrJ1gIUcVjwATFQxO 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.17 (GNU/Linux) iEYEARECAAYFAldVdnsACgkQUq8CANPxcA5vcQCfaHk4BKdo7fbUGw/j/AR8aXeE IJQAoIn1duYCye4CmSp/s5Ac+8jxcKcR =4aWw -----END PGP SIGNATURE----- --C6NLL91fkeNfCf7nPrJ1gIUcVjwATFQxO-- From nobody Mon Jun 6 09:25:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45E012D82D for ; Mon, 6 Jun 2016 09:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83aSZpZDO1tO for ; Mon, 6 Jun 2016 09:25:42 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CCF412D84B for ; Mon, 6 Jun 2016 09:25:20 -0700 (PDT) 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 89AE644361 for ; Mon, 6 Jun 2016 18:25:18 +0200 (CEST) X-purgate-ID: 152705::1465230318-0000082D-1CCFF146/0/0 X-purgate-size: 3295 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 7BCA7428F4 for ; Mon, 6 Jun 2016 18:25:18 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 492BD1A4E0; Mon, 6 Jun 2016 18:25:18 +0200 (CEST) In-Reply-To: To: tls@ietf.org Date: Mon, 6 Jun 2016 18:25:18 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20160606162518.492BD1A4E0@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] Downgrade protection, fallbacks, and server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 16:25:45 -0000 The IMO most reasonable way forward would be to side-step the TLS version negotiation through ClientHello.client_version entirely, because of the well-known interop problems. Simply use the presence of *ANY* TLSv1.2+ TLS cipher suite in the offered list of TLS cipher suites as an indication that a TLS client is capable and willing to actually _use_ TLSv1.2, even when ClientHello.client_version might indicate (3,2) or (3,1) for better interop. The same approach will work for TLSv1.3, where the presence of a TLSv1.3 could be used to tell the server that the client is capable and willing to talk TLSv1.3, even when ClientHello.client_version might indicate a lower version of the protocol. Only the client is in the position to decide whether aborting the TLS handshake and retrying with a more feature-creeping ClientHello could provide additional benefits to the client (that it previously didn't offer, for whatever reason), and only the client is in the position to know how many TLS handshake attempts with which properties it previously attempted, and when to better stop retrying automatically and silently and to perform risk management (such as warning user/admin that something odd is going on). To get a smooth migration to using newer TLS protocol versions, we first need to define a scheme that lets new implementations recognize each other without upsetting the installed base. We know what works, the code points already exist, we will just have to align the documented semantics to provide a more forward-interoperable and more reasonable behaviour. Viktor Dukhovni wrote: > >> David Benjamin wrote: >> >> I'm not sure I follow. The specification certainly spells out how >> version negotiation is supposed to work. That hasn't stopped servers >> from getting it wrong. Fundamentally this is the sort of thing where >> bugs don't get noticed until we make a new TLS version, and we don't >> do that often enough to keep rust from gathering. > > A better way to keep rust from gathering is to not instutionalize fallback, > force the broken sites to deal with the issue. It's not the sites, but rather the software vendor providing the underlying TLS implementation. Sometimes you don't actually have a choice and an alternative to using what exists. > > While 2% is noticeable, you can probably drive 1.3 version intolerance > out of the ecosystem relatively quickly if Chrome implements fallback > for a limited time (say 6 months after TLS 1.3 RFC is done) and with > a diminishing probability (60% first month, 10% less each month > thereafter), season to taste. There exist various different flavour of TLS version intolerance, and the amount of defective servers out there is probably much larger. The entire installed base of Windows 2008R2 and Windows 20012R2 is TLS version intolerant with respect to TLSv1.2. If you send propose TLSv1.2 inside an SSLv2Hello to such a server, it will negotiate TLSv1.1 (rather than TLSv1.2). If you send an extensionless SSLv3 Hello proposing TLSv1.2, these Windows server with choke and close the network connection. An extension-less SSLv3 Hello with at client_version = TLSv1.1 or TLSv1.0 will succeed. -Martin From nobody Mon Jun 6 10:22:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81FD12D871 for ; Mon, 6 Jun 2016 10:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5l5Ru6DmzIW for ; Mon, 6 Jun 2016 10:21:54 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010: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 B5A6612D0EB for ; Mon, 6 Jun 2016 10:21:53 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id b73so99025469lfb.3 for ; Mon, 06 Jun 2016 10:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=FiI7bYJ3kjuEW7Eh7jbQK2mYvgwkP1NSUFPn0dDavLo=; b=zEzO3wtT720ntfrVXiXi7CrHfygTA2D4UX5FShdnofRfZVj05H+4urcXS0KB3P8FmQ q+rPBBRIrnYT7QWFDt8xY1v0DFGf5j4i5Vxq+QMFQnkzhiSjtsx/hANGZmkkB0JHzNGe NxQpCYugWQLO4Q1Wvkfh+fcg2ylpV+x+TIaWBKxYdGeZac3gUnDbJsjoMfo8DSs4h+yW r+U9GzTpPVnt/oITsPlE40F52Nw3gqHP0x+p/SHEvO233Bagf6W1pESnnJayIZKoUK+m BGg8ydvhEkr1h+zMmmZB7i8TdmOzRXLArQ6LhFIfKUuLF3bnItIxtPs+7XAA8z/N1Gy7 e+8g== 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; bh=FiI7bYJ3kjuEW7Eh7jbQK2mYvgwkP1NSUFPn0dDavLo=; b=SOiNO7+zuUCNaf0ayJof8gC0Th3Xsai2wiA494dHzKKLt7WsdtB5yxlQbYouvAYwu5 8zwP0VN/320JDn4DAigNwqycYfLDznRfT4QCCDtyN6B3WBGAnMKYYFKp5AWioKEGdECz rSqlHqpIXpbFDc1Z3YL6nMIdkpznodbeL+NyR8j2QEEqk2mZhwRg1HOiR5abFqwWWSIC 14KsdQqsKIl6awQpbsFKfteJ/qT0oUC592Yh0uigHB2H0qDRluMCIaJu8/QE1jTvUDGx CyeB486myfWMXiWCCuz1QJuUebAV0tv8aKJpUC+g923jdLBE+Py2Eq6R9qSNE7rqp5q8 MZhw== X-Gm-Message-State: ALyK8tLsQjxDcnAlM/fMHPF9GvkiGdhmKQ3RkWBhrB2IIgZ8gjCfmvTltIU6QgOGip8bQKK8TJ4swW0njAGycw== X-Received: by 10.25.91.196 with SMTP id p187mr1768896lfb.167.1465233711895; Mon, 06 Jun 2016 10:21:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.153.135 with HTTP; Mon, 6 Jun 2016 10:21:12 -0700 (PDT) In-Reply-To: <20160606171459.20797.7839.idtracker@ietfa.amsl.com> References: <20160606171459.20797.7839.idtracker@ietfa.amsl.com> From: Ted Lemon Date: Mon, 6 Jun 2016 13:21:12 -0400 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a11412792e92ab605349f4e9d Archived-At: Subject: [TLS] Fwd: I-D Action: draft-lemon-tls-blocking-alert-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 06 Jun 2016 17:21:59 -0000 --001a11412792e92ab605349f4e9d Content-Type: text/plain; charset=UTF-8 I've posted a new document to the datatracker that adds some TLS alert codes that can be sent to indicate that a particular TLS request has been blocked by the network. This attempts to address the problem of notifying the user of what went wrong when a site is blocked, without creating a channel that can be used by a hostile network to attack a user. Feedback is solicited, naturally. Thanks! A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Blocked Site Alerts for TLS Author : Ted Lemon Filename : draft-lemon-tls-blocking-alert-00.txt Pages : 7 Date : 2016-06-06 Abstract: Hosts connecting to the Internet should generally be able to connect to all available services. However, as a matter of policy, need or preference, some services may be blocked by the network. TLS correctly treats attempts to communicate the reason for such blockage to the client as an attack. This memo describes a safe way for hosts to be notified using the TLS alert mechanism that a connection has been blocked by the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-lemon-tls-blocking-alert/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-lemon-tls-blocking-alert-00 --001a11412792e92ab605349f4e9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've posted a new document = to the datatracker that adds some TLS alert codes that can be sent to indic= ate that a particular TLS request has been blocked by the network. =C2=A0 T= his attempts to address the problem of notifying the user of what went wron= g when a site is blocked, without creating a channel that can be used by a = hostile network to attack a user.

Feedback is solicited, naturally.

Thanks!

A New Internet-Dr= aft is available from the on-line Internet-Drafts directories.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Blocked Site Alerts for TLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Ted = Lemon
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-lem= on-tls-blocking-alert-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-06-06

Abstract:
=C2=A0 =C2=A0Hosts connecting to the Internet should generally be able to c= onnect
=C2=A0 =C2=A0to all available services.=C2=A0 However, as a matter of polic= y, need or
=C2=A0 =C2=A0preference, some services may be blocked by the network.=C2=A0= TLS
=C2=A0 =C2=A0correctly treats attempts to communicate the reason for such b= lockage
=C2=A0 =C2=A0to the client as an attack.=C2=A0 This memo describes a safe w= ay for hosts
=C2=A0 =C2=A0to be notified using the TLS alert mechanism that a connection= has
=C2=A0 =C2=A0been blocked by the network.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-lemon-tls-blocking-alert/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-lemon= -tls-blocking-alert-00
--001a11412792e92ab605349f4e9d-- From nobody Mon Jun 6 11:54:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB1712D75B for ; Mon, 6 Jun 2016 11:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDVAihn5On3X for ; Mon, 6 Jun 2016 11:53:56 -0700 (PDT) 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 185DE12B05A for ; Mon, 6 Jun 2016 11:53:56 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id s186so57083218qkc.1 for ; Mon, 06 Jun 2016 11:53:56 -0700 (PDT) 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-transfer-encoding:message-id; bh=UX9Rco2BCC7lDORxrSiq24Nhqte8EvCMCVi7HAsIYjU=; b=eDrl4c5mslFUf+nlMZ+7yRtoLHNnaQey1gCI5NG6dzbcL12+9I89TcpNV19sEePNBG mjKnXZ9HsDN46uHY50YZOGnOPn0b8obr+m0HxswDWBIsgmah6QgzNHKEUC2tITeCuKm9 AD26wZ1vXxXzfdkjZ5z5xhk4FmN41GnCjxBYJFFQKT1bZ8YguvYXzEpbSu9YjK54FJfF YJ+SdNA8HLc/Z9bGJm3zezUFWnVTaI7AWTtmM801/BmdO4tGh7eqN5GunGovKy6IlVJo GA8KudC3FPQU8SiwV3IOczkRl3IDShSMmfeYmFLylfsKa+7Hcybvv7ggNsker7G/O1mS /3jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=UX9Rco2BCC7lDORxrSiq24Nhqte8EvCMCVi7HAsIYjU=; b=kuMev1l2XBPMTBZUdSp1wNVZvJ5828SFcAXTz+Mf3CTWiKL2sGrAcLVNTt19R+c+Re LJkIYBKel9NBDgZxJ9kkOUIarYGp08otD/fKkIMRcokrOh1wzvldeP7O4KLNC9ksD51/ QtXao5keiYIknAZfwSXaaJyH8wkV6gQJ1LLJYffxhkhDOiEAqKP3/pB6hw9QxM/zcHJK ovdP428I/ykXEj1FFm0pwejbn+Vto3qFUj7ZiKSB8WgDbH5jP4Sjk8cwRIezWxmSzkVC sdGXSq5pYtLZUb7+tnilCjXX/aC+ET9YOu/7uPQLWMMvaQdwxc+O0h/0/0s7IdF0hPjc aT2g== X-Gm-Message-State: ALyK8tKYJVGgir3dKkSTcC2fcCl42KGrZ5wOikyAHVKjEm7GjTATo8LWMLwrs+3Tl2iP4w== X-Received: by 10.55.103.84 with SMTP id b81mr17802260qkc.177.1465239235238; Mon, 06 Jun 2016 11:53:55 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id m25sm6028221qta.43.2016.06.06.11.53.54 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 06 Jun 2016 11:53:54 -0700 (PDT) From: Dave Garrett To: Hubert Kario Date: Mon, 6 Jun 2016 14:53:53 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201606031616.14451.davemgarrett@gmail.com> <1612869.mrh4f7qht5@pintsize.usersys.redhat.com> In-Reply-To: <1612869.mrh4f7qht5@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201606061453.53336.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 06 Jun 2016 18:53:58 -0000 On Monday, June 06, 2016 06:48:20 am Hubert Kario wrote: > What makes you think that a new version negotiation that works more or=20 > less in the same way will _not_ be implemented incorrectly? The list-based extension doesn't work in quite the same way. The current me= chanism compares two values and picks the lower one. This new mechanism com= pares two lists and picks the highest mutually listed. Also note that I wis= h to officially drop any meaning from the version IDs such that we're using= an arbitrary 16-bit serial number rather than two 8-bit major & minor numb= ers. The new supports discontinuous lists, e.g. support of 1.0, 1.2, & 1.4,= but not 1.1 or 1.3, without risking accidental negotiation of a lower vers= ion that isn't desired. (if 1.3 is eventually declared less ideal than 1.2 = or 1.4 due to some unforeseen problem, this gives us a safe mitigation, and= it extends to arbitrary future scenarios) Also, as with any new system, we= now have the ability to loudly stress to TLS 1.3+ implementers to not scre= w it up and test for future-proofing this time around. At a minimum, implem= entations will not be able to use the exact same code to negotiate in both = systems and would have to go out of there way to add intolerance stupidly, = rather than stumble into it stupidly again. Just sticking a new field in an= extension lets implementers route it into the same code and risk the same = mistakes; adding a bit of complexity here is an unfortunate cost of fixing = this mess. Just adding a new _empty_ extension, as was more recently propos= ed, is something I think could also work ok. Again, if we're more likely to= get consensus on that, I think it's viable too. The idea of a compliance test suite has come up before and I will again say= : YES, PLEASE! I certainly don't claim anything proposed here is perfect, but nothing is o= r will be in a 20 year old protocol. Dave From nobody Mon Jun 6 12:32:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A401512D5CF for ; Mon, 6 Jun 2016 12:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BIGNUM_EMAILS=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TajhVckeu6P for ; Mon, 6 Jun 2016 12:32:39 -0700 (PDT) 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 A9AA712D550 for ; Mon, 6 Jun 2016 12:32:39 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id o189so137677677ioe.2 for ; Mon, 06 Jun 2016 12:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/n2OlCDoX1+q0UrDzL6u9pbtXwqIwJFQWTyIDbdLJqI=; b=yNHxUIOyrqXJLKwJ+g4DTp8YK6SVc/u2Yx5a2vAjzxkpLstXCWpI00wUr/htya099v Bin9xd/3bMBYBIZj/llLHUR7ykzJcpalXuDys8XpG1aEpJeWHMfzfW0O+9AHdb44fJFB jHFtNXjHdvh0/FFydOLWRn0DlxpO64j2oJUSqVOEZrdov4dmmjQQEm9xpIyv17z57sqv pMSBu28X9SZZGTiBcO8LoavKmO3J5XhcILMJ0zVslggtiY71ZJ9w4+nRi26yNX50Z5gJ kwGHO+m8ogsukRwUP+8hs2GTDByWkaouoIsdZYXYwepLHwtkrXhpCF92ZjH7fRcroTnJ UycA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=/n2OlCDoX1+q0UrDzL6u9pbtXwqIwJFQWTyIDbdLJqI=; b=cSSUePz60ruyp90CRre9NTQnA0PaEq2xALM65i5Ib+nztM8E7W09ShpFtrogCumvq1 rcZ2ytMCM4FUps5wNc7aWTjZRbEGUi6udCAiax3R2L3cSM9Cu5NUpJsfASLM6j2EX4s1 WRncMyL10jgEzk9ufi+3bOexbcWjMITXtgaVaG+mdkZ1kIPWvjHE6tuN535kinGUYqnf mlC2nBrdwa2Zb93HzzeTLzz+SY9XowJmvQgk71q5w4M2OIWVavZ3TDRkdyyqv7C9INno lQHQTr3e6lBSTVX5Vab9V3R3wpvXMYXFnXRRezVholE6ySUs2IC/gRWurI7BK3ecXxbc 0m7Q== X-Gm-Message-State: ALyK8tK/+GcK/TAZLJhHEXc+sFiXEp4EObYPEA9wtOGKSp0em9vk4fWvNKz0pT4HM/RWIGi9/2hZSiYFZLggow== X-Received: by 10.107.179.136 with SMTP id c130mr24126133iof.130.1465241558893; Mon, 06 Jun 2016 12:32:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.129.1 with HTTP; Mon, 6 Jun 2016 12:32:38 -0700 (PDT) In-Reply-To: References: <1706151.1Qo9uxO9Hr@pintsize.usersys.redhat.com> From: Jeffrey Walton Date: Mon, 6 Jun 2016 15:32:38 -0400 Message-ID: To: Bill Frantz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 06 Jun 2016 19:32:42 -0000 >> That being said, I would prefer the solution to be a compliance test suite >> that checks if servers do handle correctly future versions, future >> extensions and future ciphersuites correctly. > > I agree with Hubert. The big question is how you get the bug report to the > server operator. > > With servers which are currently maintained, it should be possible, although > difficult in specific instances to contact the owner. With servers which > aren't being maintained, e.g. those in imbedded devices, the problem becomes > much harder. There are two ways. First, use the Administrative and Technical contacts in the WHOIS database. They are ICANN contractual requirements, and they must be valid. Second, RFC 2142, MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS. Jeff From nobody Mon Jun 6 23:00:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA1912B02F for ; Mon, 6 Jun 2016 23:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUGMEqKMMwGQ for ; Mon, 6 Jun 2016 23:00:40 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE37128B44 for ; Mon, 6 Jun 2016 23:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1465279240; x=1496815240; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XbgF0BS4joBa/jtyXoHqN6WdE21YNZzx8CWVPX8N8eU=; b=4pSAVCydFXNFU+BQ4Z8cfiAb6Su3VQGfP9E0gbFdTjnYF3up5jV5LSer jJN/+H5fJCcMBAade3p6Va/Iwv4JBs56qLgy7Qi/G+odBVOuMUtlFLeuL eZcl4JNuAUQOA1xYao42BMSO5iJtfMk1HIfRvqFIyDu0XjARMeWP+h8py ZM8/m1cVuNK7IXa8oXcOitHSkoM9ymrQx02Ll3CvsyohF73hXlIO93nD9 8gzTK2gsBqdrqp+uOK347dtYRcYyHcbjaLPQPpYPUhF80CoSmKfn1M3sA JO7OS/wGYzamh2+iDCOpeZuJPeIL9THvhACenvhqeMzYVSHafrM5ymawY g==; X-IronPort-AV: E=Sophos;i="5.26,431,1459771200"; d="scan'208";a="90097599" 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; 07 Jun 2016 18:00:34 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Tue, 7 Jun 2016 18:00:34 +1200 From: Peter Gutmann To: Dave Garrett , Hubert Kario Thread-Topic: [FORGED] Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] Thread-Index: AQHRvOCpkwKytQA9xE+nC5GWXc1elZ/WTVyAgAANXACAAJ0zAIAAQ0wAgAAK6ACAACCCgIAEGFQAgACHqYCAAYNcSw== Date: Tue, 7 Jun 2016 06:00:33 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C9D3F0@uxcn10-5.UoA.auckland.ac.nz> References: <201606031616.14451.davemgarrett@gmail.com> <1612869.mrh4f7qht5@pintsize.usersys.redhat.com>, <201606061453.53336.davemgarrett@gmail.com> In-Reply-To: <201606061453.53336.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: [10.6.2.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] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2016 06:00:45 -0000 Dave Garrett writes:=0A= =0A= >Also, as with any new system, we now have the ability to loudly stress to = TLS=0A= >1.3+ implementers to not screw it up and test for future-proofing this tim= e=0A= >around. =0A= =0A= I think that's the main contribution of a new mechanism, it doesn't really= =0A= matter whether it's communicated as a single value, a list, or interpretive= =0A= dance, the main thing is that there needs to be a single location where the= =0A= version is given (not multiple locations that can disagree with each other = as=0A= for TLS < 1.3), and the spec should include a pseudocode algorithm for deal= ing=0A= with the version data rather than just "implementations should accept thing= s=0A= that look about right".=0A= =0A= Peter.= From nobody Tue Jun 7 02:55:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC07D12D5D5 for ; Tue, 7 Jun 2016 02:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.328 X-Spam-Level: X-Spam-Status: No, score=-8.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wm4kDuWdSB1g for ; Tue, 7 Jun 2016 02:55:53 -0700 (PDT) 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 B020012D576 for ; Tue, 7 Jun 2016 02:55:53 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 38CE37F08C; Tue, 7 Jun 2016 09:55:53 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-122.brq.redhat.com [10.34.0.122]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u579tp82011562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jun 2016 05:55:52 -0400 From: Hubert Kario To: tls@ietf.org Date: Tue, 07 Jun 2016 11:55:50 +0200 Message-ID: <3372929.xMFAkkVyhb@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.11-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: References: <20160606171459.20797.7839.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2022749.zYvfn1A8HX"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 07 Jun 2016 09:55:53 +0000 (UTC) Archived-At: Subject: Re: [TLS] Fwd: I-D Action: draft-lemon-tls-blocking-alert-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2016 09:55:55 -0000 --nextPart2022749.zYvfn1A8HX Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 06 June 2016 13:21:12 Ted Lemon wrote: > I've posted a new document to the datatracker that adds some TLS aler= t > codes that can be sent to indicate that a particular TLS request has > been blocked by the network. This attempts to address the problem > of notifying the user of what went wrong when a site is blocked, > without creating a channel that can be used by a hostile network to > attack a user. why separate malicious_site and policy_violation? Why not provide just = a=20 single administratively_prohibited? I don't see a difference to the=20 user, in both cases the site will remain unavailable when retrying=20 connection and in both cases if the user thinks it's a mistake he or sh= e=20 will need to contact the network administrator. I don't understand the account_attention_* alerts. What account does th= e=20 user need to log in? In what scenarios would they be used? How is it=20= different from the captive_portal? =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 --nextPart2022749.zYvfn1A8HX 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 iQIcBAABCgAGBQJXVponAAoJEJKo0bgB0vX1oH0P/3heKiLJJ1oeVc/FjEP8pdty BFBSpfDgSRWPMFB7K6NtaNHBZb7IGgPINrKXotxrbCgWc1hPy6qTJfhmaHsu5/iC UyeEzGcWbtE1iplkd7vpBolcVN82eYpQqUyp1b8/0t8O/W/UbrkzmpMOX0skdAiW i6AkwhuwKGl8JvCRr5hvZe1Dy8QPjkZkvaR59J4meLBDyW3B0B/dUpvmAJKVTr+v Lytp0Rbfcyd0xHulSU7FyQe126ronOpHumhEPmE4XslxU7Ygnj6q0xtVCFTi1g6l OFuZUDDweIXHGhQt77NWeICkiv31U5+NBM4JHF1P5O6mlv7P8Lq7M7OMbbIkY57U N/55KPJMDxlGdibuRf7hsdS1kdUNhWflwNjiI81R0jSZPf9U4umV+eIEoAaYRj7X iOWms19YqkC8ctNWeWNV6oP0DqDRHu6EftYVzyIxFvuB3VkEaFmoyEO284nTPs8W uwasdTKin7t7ol6whAz/xp8ZFclChgo8FpVVc80s0wtSc1gODUymDDkipe3miHif +JVuA6ioW6JDYgGIyC7gaC1v/LxY3C6zwm+PyC+wGV+hMUHhOcJan2cASKpkEu1o DKgqiq3UQgFzNAjbAQhcil96dIB1EXM2fN0eI3DuRmhZjjeExlTHsX5E+O5cmYJw TQXviw8F3hWW3AADVqMj =ZSXv -----END PGP SIGNATURE----- --nextPart2022749.zYvfn1A8HX-- From nobody Tue Jun 7 07:22:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC1812D68A for ; Tue, 7 Jun 2016 07:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gedf19aVYB9p for ; Tue, 7 Jun 2016 07:22:25 -0700 (PDT) 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 DD82512D6A6 for ; Tue, 7 Jun 2016 07:22:21 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id s186so69140249qkc.1 for ; Tue, 07 Jun 2016 07:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=sA+zowR8dY0cvKhGiuflWxWTLFR1c9A5eH3CRMogGI8=; b=P2RqhQvsPC656prp2QTUAbElWAJWghaI1oVofX4TArX10eYQQXifB2QS8dLCcZTpKt bnVGlLW1ml/QSWoz4skdVe2SuLhhs6NOMcl7Jk4lAi6iXOl604eZXThlvyvMrvQP0O5/ TPLx1QbFxdmPfWVgxu1YfDPRKfHml5nLaOn/Q= 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; bh=sA+zowR8dY0cvKhGiuflWxWTLFR1c9A5eH3CRMogGI8=; b=BTg43RjxaiOGlOHOx9gv9hdwNfYQMqVG9sbXxhMQD9rqLsXYGFD/sc5JK0x6opHmrm yR0eCaqXuAy6L8pBfsiZicwPBXpJytCCamVJczumI1Od7HtP8KGu2OevmOaZ6XpSKeUc xJjmvuyG8vz4lC5jQDYBW3MGPLGCk/NVTGZcUUKUV3BDeoK2BnnNa4KkUTam6MYo01JN NzfVmaRkUh3bsaDscS2RnpwN5ECHw3osH0Dwd6D8+bka7eNzhXmxW5QQqVD+A4pj8R9C 0pQrEDlU9v51TvmWRhZdjxOz4jxawy0c53r/bpD7xIMWq+bUUivUpWdj9gLO9daN41LX AMwQ== X-Gm-Message-State: ALyK8tLE/0n6d8Y5+yT/vJqB0uWJpudpn6iRiUG+XLoEC/Y8pWA1VtxAiHfVh2HukkShDYDaGiVjEY5hGdZASA== MIME-Version: 1.0 X-Received: by 10.55.76.84 with SMTP id z81mr21828863qka.17.1465309341097; Tue, 07 Jun 2016 07:22:21 -0700 (PDT) Received: by 10.55.96.130 with HTTP; Tue, 7 Jun 2016 07:22:20 -0700 (PDT) X-Originating-IP: [107.77.192.103] Received: by 10.55.96.130 with HTTP; Tue, 7 Jun 2016 07:22:20 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C9D3F0@uxcn10-5.UoA.auckland.ac.nz> References: <201606031616.14451.davemgarrett@gmail.com> <1612869.mrh4f7qht5@pintsize.usersys.redhat.com> <201606061453.53336.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C9D3F0@uxcn10-5.UoA.auckland.ac.nz> Date: Tue, 7 Jun 2016 10:22:20 -0400 Message-ID: From: Kyle Rose To: Peter Gutmann Content-Type: multipart/alternative; boundary=001a11487ed6c33c690534b0eae5 Archived-At: Cc: "" Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2016 14:22:42 -0000 --001a11487ed6c33c690534b0eae5 Content-Type: text/plain; charset=UTF-8 I'm a big fan of the idea of a very strict qualification suite, as well, to try to head off some of these problems before (faulty) implementations proliferate. Hackathon? Kyle On Jun 7, 2016 2:00 AM, "Peter Gutmann" wrote: > Dave Garrett writes: > > >Also, as with any new system, we now have the ability to loudly stress to > TLS > >1.3+ implementers to not screw it up and test for future-proofing this > time > >around. > > I think that's the main contribution of a new mechanism, it doesn't really > matter whether it's communicated as a single value, a list, or interpretive > dance, the main thing is that there needs to be a single location where the > version is given (not multiple locations that can disagree with each other > as > for TLS < 1.3), and the spec should include a pseudocode algorithm for > dealing > with the version data rather than just "implementations should accept > things > that look about right". > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11487ed6c33c690534b0eae5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm a big fan of the idea of a very strict qualification= suite, as well, to try to head off some of these problems before (faulty) = implementations proliferate.

Hackathon?

Kyle

On Jun 7, 2016 2:00 AM, "Peter Gutmann"= ; <pgut001@cs.auckland.ac.n= z> wrote:
Dav= e Garrett <davemgarrett@gmail.= com> writes:

>Also, as with any new system, we now have the ability to loudly stress = to TLS
>1.3+ implementers to not screw it up and test for future-proofing this = time
>around.

I think that's the main contribution of a new mechanism, it doesn't= really
matter whether it's communicated as a single value, a list, or interpre= tive
dance, the main thing is that there needs to be a single location where the=
version is given (not multiple locations that can disagree with each other = as
for TLS < 1.3), and the spec should include a pseudocode algorithm for d= ealing
with the version data rather than just "implementations should accept = things
that look about right".

Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a11487ed6c33c690534b0eae5-- From nobody Tue Jun 7 07:34:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C194C12D694 for ; Tue, 7 Jun 2016 07:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.328 X-Spam-Level: X-Spam-Status: No, score=-8.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6PqrctyYwFH for ; Tue, 7 Jun 2016 07:34:18 -0700 (PDT) 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 80EAB12D69C for ; Tue, 7 Jun 2016 07:34:14 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 00131627EC; Tue, 7 Jun 2016 14:34:13 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-122.brq.redhat.com [10.34.0.122]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u57EYCuF002173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jun 2016 10:34:13 -0400 From: Hubert Kario To: Kyle Rose Date: Tue, 07 Jun 2016 16:34:06 +0200 Message-ID: <2698023.3YM6Cv9mer@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.11-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4C9D3F0@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1524470.ggfxFv7uvX"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 07 Jun 2016 14:34:14 +0000 (UTC) Archived-At: Cc: "" Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2016 14:34:22 -0000 --nextPart1524470.ggfxFv7uvX Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 07 June 2016 10:22:20 Kyle Rose wrote: > I'm a big fan of the idea of a very strict qualification suite, as > well, to try to head off some of these problems before (faulty) > implementations proliferate. >=20 > Hackathon? I have two approaches I'm working on, they are missing a nice interface= =20 though. The first one is: https://github.com/tomato42/tlsfuzzer and aims to be a comprehensive test suite=20 and the other one, simpler (aimed only at detecting incompatibilities)=20= is cscan that lives here: https://github.com/tomato42/cipherscan/tree/cscan-2 Both require just python and have minimal dependencies. > Kyle >=20 > On Jun 7, 2016 2:00 AM, "Peter Gutmann" =20= wrote: > > Dave Garrett writes: > > >Also, as with any new system, we now have the ability to loudly > > >stress to>=20 > > TLS > >=20 > > >1.3+ implementers to not screw it up and test for future-proofing > > >this>=20 > > time > >=20 > > >around. > >=20 > > I think that's the main contribution of a new mechanism, it doesn't= > > really matter whether it's communicated as a single value, a list, > > or interpretive dance, the main thing is that there needs to be a > > single location where the version is given (not multiple locations > > that can disagree with each other as > > for TLS < 1.3), and the spec should include a pseudocode algorithm > > for dealing > > with the version data rather than just "implementations should > > accept > > things > > that look about right". > >=20 > > Peter. > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls =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 --nextPart1524470.ggfxFv7uvX 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 iQIcBAABCgAGBQJXVtteAAoJEJKo0bgB0vX12NgP/j1eUtFu887a7UOQM7frbtkk FXHjFRKyhhdslX4y6Clg0dSBzhTOFH0oaf7LCgfrW0xwUbbYVvVTmTk8HwmUcapt Y+yABxWjbUsiPhGduYSFE0iIP43ax7AGHaknA1UNhkyWXtnAI5jAdilPQvH/ZPpS /3ND+Ul6G+DU5ZRcta0Q8UFfvPiBIdOOWo7LwB9iRrcdc2gKrbQZWrdkH9Tgf7VP rM9VXOdCT2JgE+Bqbm3+LFowGqfouOTibnYRs8vIw80kdqefEpbS71FVcpojOuBV 0hDerkDeIXB3AieKnkbEakwdGh9FSHFdFBNYSnko6CwJkjpP7SJ8hLifLQQSAbqy 878FlmPjZMenWRAB07KSLiJeF89a8g35uIo2OJwQ5VYkb7c06JHbtOnA4jDH8S/S NMNYsDCtSgZupnk36SJDKd5C2RGx3GXhbXVW7X1m1SWxScLja9+1+evv3z9m1F99 AzjThC8y8DF0GPPWSQeoggW24LMqQnp1doK1xvSU8X1PgJjEx6+yRwvuqa1E9Fs9 HUDxWEKd7BhTqv4Xh6Z2L3tyGAxUzUI3hu7PQih3Ao2rnyyTcEUyBU4OWkJFAwop Eas4H2VAwvHTiMFc2xfVlBh+AICkOhAKbZllp3sku3K4b0vHfcz9j7c+bBqHXC+O DXqn3fXfWhXvHx0n+3/P =UTUN -----END PGP SIGNATURE----- --nextPart1524470.ggfxFv7uvX-- From nobody Tue Jun 7 07:36:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D2812D6A1 for ; Tue, 7 Jun 2016 07:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObumoFPqbHBB for ; Tue, 7 Jun 2016 07:36:09 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c: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 02E8F12D694 for ; Tue, 7 Jun 2016 07:36:08 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id m124so117366160wme.1 for ; Tue, 07 Jun 2016 07:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=3cn1sVl4E44FKe1PSdOrWtwVGXx1j9l9rS3IIxo9rLw=; b=Sh5Vm30kefCC4kkQxnRmBBuZVkxieBJKa3WRHLvK8yI4QZbaljH5gnk8zz61iBodWL TQukTc1yWBCJXL/BkY2pqspEtSvGO+nRH3ogHg6Isbe3lMhCMejo1XBo+iaf8uer8kH5 VJc403/ILNfqZ7wKnOzlOw13oncoqTiNu3VhHf3BSVVhyIdnU4coks6K06bztkGICCRV 5pxD5NozfId1KxYHNJLvSAm0EWbsl4mbAjAtqUh7LM8ipz2Ct4OiZ/e8qH5AYBSRcLTu 93dMXqkmvMj6dy9mmeS/fUHnlIvrN9b5HAoaKDWnxre0noWsaASJ/d8i+r3EAK7YFOoq FR0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=3cn1sVl4E44FKe1PSdOrWtwVGXx1j9l9rS3IIxo9rLw=; b=JZq5TUQQVLTtH5HPU1NzQggY3ZqFOGgrSGPfWeRxMf2rkNFsN2L5GgV+C5prm1nsn1 7nO9OgS9uIKLt2oFEhF0vukjldPHWcZmuF8XSEMt6uVZO0EGdbCW9FiZ6vVsOFuWnX2B XARn+ST82aayqBdqw5nIProNnbUNWle2IqzBNzujO8io5ndjGSJBLfDpCNrg/u3ELZbj 7y2R3zGpuN6xMwOCuQJRHbeze829LhcxrDXBtrd0DUzU2IC63792JgJqNZQTx7GS5YK5 mhLsYeNCTTWyo45lVgSs5AAXByh2P7wcHKF0+F642ZOSC8Z4BZSvUXRFhwHbb6/D9mD9 TGdg== X-Gm-Message-State: ALyK8tJXm70Rx/9Ee/6igN9qsoOJvaLQwT6Hn/ndVjBtxqH+KKghvo8kuKFUi5kTF3LtYQ== X-Received: by 10.28.30.16 with SMTP id e16mr69083wme.20.1465310167554; Tue, 07 Jun 2016 07:36:07 -0700 (PDT) Received: from [172.24.250.135] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id db6sm25795343wjb.2.2016.06.07.07.36.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Jun 2016 07:36:03 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_67589B2F-99F8-4C43-9E05-16423BB27102" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Tue, 7 Jun 2016 17:36:01 +0300 Message-Id: <19D9A152-3801-44DA-ADF0-345011EDF54D@gmail.com> References: <201606031616.14451.davemgarrett@gmail.com> <1612869.mrh4f7qht5@pintsize.usersys.redhat.com> <201606061453.53336.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C9D3F0@uxcn10-5.UoA.auckland.ac.nz> To: Kyle Rose X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2016 14:36:10 -0000 --Apple-Mail=_67589B2F-99F8-4C43-9E05-16423BB27102 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m not sure this helps.=20 I=E2=80=99ve never installed a server that is version intolerant. TLS = stacks from OpenSSL, Microsoft, Java, and most any implementation we can = name have been version tolerant forever. Certainly none of us can name = any implementation that at any point had a version out that was tolerant = (or implementing) TLS 1.2 but intolerant of TLS 1.3. And these are the same implementations we=E2=80=99re likely to = participate in a bakeoff or run the suite we create in the hackathon. Yoav > On 7 Jun 2016, at 5:22 PM, Kyle Rose wrote: >=20 > I'm a big fan of the idea of a very strict qualification suite, as = well, to try to head off some of these problems before (faulty) = implementations proliferate. >=20 > Hackathon? >=20 > Kyle >=20 > On Jun 7, 2016 2:00 AM, "Peter Gutmann" > wrote: > Dave Garrett > = writes: >=20 > >Also, as with any new system, we now have the ability to loudly = stress to TLS > >1.3+ implementers to not screw it up and test for future-proofing = this time > >around. >=20 > I think that's the main contribution of a new mechanism, it doesn't = really > matter whether it's communicated as a single value, a list, or = interpretive > dance, the main thing is that there needs to be a single location = where the > version is given (not multiple locations that can disagree with each = other as > for TLS < 1.3), and the spec should include a pseudocode algorithm for = dealing > with the version data rather than just "implementations should accept = things > that look about right". >=20 > Peter. > _______________________________________________ > 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 --Apple-Mail=_67589B2F-99F8-4C43-9E05-16423BB27102 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99m not sure this helps. 

I=E2=80=99ve never installed a server = that is version intolerant. TLS stacks from OpenSSL, Microsoft, Java, = and most any implementation we can name have been version tolerant = forever. Certainly none of us can name any implementation that at any = point had a version out that was tolerant (or implementing) TLS 1.2 but = intolerant of TLS 1.3.

And these are the same implementations we=E2=80=99re likely = to participate in a bakeoff or run the suite we create in the = hackathon.

Yoav

On 7 Jun 2016, at 5:22 PM, Kyle = Rose <krose@krose.org> wrote:

I'm a big fan of the idea of a very strict qualification = suite, as well, to try to head off some of these problems before = (faulty) implementations proliferate.

Hackathon?

Kyle

On Jun 7, 2016 2:00 AM, "Peter Gutmann" = <pgut001@cs.auckland.ac.nz> wrote:
Dave Garrett <davemgarrett@gmail.com> writes:

>Also, as with any new system, we now have the ability to loudly = stress to TLS
>1.3+ implementers to not screw it up and test for future-proofing = this time
>around.

I think that's the main contribution of a new mechanism, it doesn't = really
matter whether it's communicated as a single value, a list, or = interpretive
dance, the main thing is that there needs to be a single location where = the
version is given (not multiple locations that can disagree with each = other as
for TLS < 1.3), and the spec should include a pseudocode algorithm = for dealing
with the version data rather than just "implementations should accept = things
that look about right".

Peter.
_______________________________________________
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

= --Apple-Mail=_67589B2F-99F8-4C43-9E05-16423BB27102-- From nobody Tue Jun 7 07:47:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C57A12D732 for ; Tue, 7 Jun 2016 07:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0eGlq2STjDu for ; Tue, 7 Jun 2016 07:47:43 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 14ACA12D6A6 for ; Tue, 7 Jun 2016 07:47:43 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DFBE220001F; Tue, 7 Jun 2016 14:47:39 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id C9C8020000A; Tue, 7 Jun 2016 14:47:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1465310859; bh=eLRZBJ69UJTSDBZhpFFyZBFxt2dWOP5BcLKcou+sIPM=; l=140; h=From:To:CC:Date:References:In-Reply-To:From; b=CQCQzf/TZpkySviLqIaVV5gMV+YM495h9ESPVSWx7jYyQbzJTBGy/AGrsxnbVpczh VOz8i2WY1ABs+SKVE+Ozbi3f2tQMUiR2uAvfE9GZufWWJYh2xKFPrJt1oO5odiK06E 0sSC2aDtpvWH+C2qqLr0BfCMczp2LdCHlrFtkVHs= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id AF40D98082; Tue, 7 Jun 2016 14:47:39 +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.1130.7; Tue, 7 Jun 2016 10:47:39 -0400 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.1130.005; Tue, 7 Jun 2016 10:47:39 -0400 From: "Salz, Rich" To: Yoav Nir Thread-Topic: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] Thread-Index: AQHRwIHzTpAtqDdnyUWqje2bUE8okZ/eUgoAgAAD04D//8AVwA== Date: Tue, 7 Jun 2016 14:47:39 +0000 Message-ID: <8e0bc53c8a934f58973923aea2c8998b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <201606031616.14451.davemgarrett@gmail.com> <1612869.mrh4f7qht5@pintsize.usersys.redhat.com> <201606061453.53336.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C9D3F0@uxcn10-5.UoA.auckland.ac.nz> <19D9A152-3801-44DA-ADF0-345011EDF54D@gmail.com> In-Reply-To: <19D9A152-3801-44DA-ADF0-345011EDF54D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.223] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2016 14:47:44 -0000 PiBJ4oCZbSBub3Qgc3VyZSB0aGlzIGhlbHBzLsKgDQoNCkknbSBwcmV0dHkgc3VyZSBpdCB3b3Vs ZG4ndCBoZWxwIGF0IGFsbCwgZm9yIHRoZSByZWFzb25zIHlvdSBsaXN0Lg0K From nobody Tue Jun 7 08:05:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1809512D768 for ; Tue, 7 Jun 2016 08:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hTe11tnn72K for ; Tue, 7 Jun 2016 08:05:54 -0700 (PDT) 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 B9CF712D5AA for ; Tue, 7 Jun 2016 08:05:53 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id n184so141682552wmn.1 for ; Tue, 07 Jun 2016 08:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+g4IJPfZNac4oekLT1PxRiYWa/T2KpOh/vZs6pTsOiw=; b=tvS/mDNuqzUCPrceAD4RzqrWcSMiw1DkMXThmyLunj/7nIErdsuH3ge14IU5sWtQMH jP8991NqnseHbdIOSZ4GMVcaRnpevgxO+OV8VkRoxtr3/YNgF1pzXOv14lTauC+jIVF+ fAluUVxPNlWLb3urPYB1Wv0y5WlictauQ8Ydp1e4HCY88wFr4NkcPN5tRVR11rTF+wkb rpbE9qjv+UJ+uVLpkJquD97vgFYXpUOMilq1ef+dbXX87mpM7+YBJVo3eYItOyFuRIr1 LSQJ2FKlgpUnfiasMEktKB7mr3kk3cpK/i13y+RKveBkNrupBxELuzGmBxIkAkIBL4QB s+Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+g4IJPfZNac4oekLT1PxRiYWa/T2KpOh/vZs6pTsOiw=; b=R9ecz1xDE3Ln+r0dftJrzoDSLWAU9pdUxmr1gVasWrSTbfSanUIIPMHJpe0jfjCoCm YXcBucHq8dSZSyvS/6tdcTftxHQRNSnDNTdsmPx9TtL0/xX+OLqP/J+H+bNJ4H+E9+VT RXiBgP+oAeWNj/5sQI1x/9DV/fMp5xXlT6E43qwMSHjlNXDsutc1fO+s1VMuX+0rnZfV gt/Vd+DL1ROBShPyuMFFWt0Jj1oDDkNrekAkdeIK+q2BrfWyfumC0RvRQZUYDEsKnqrY kkThfKdXebmgQSE+pbdV1PrU9/vWItbseN6TTC1iKvGd62w9SPnDNCTUbo1j8SMoiBOC 5V9Q== X-Gm-Message-State: ALyK8tJErgpwzT5x1vvZcvyiBqPd8zx2z3FZs8p9jbLPorYakJQJ1POILBg1+Vx5viieUQ== X-Received: by 10.28.150.81 with SMTP id y78mr1780924wmd.37.1465311952288; Tue, 07 Jun 2016 08:05:52 -0700 (PDT) Received: from [172.24.250.135] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id hq2sm7792813wjb.36.2016.06.07.08.05.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Jun 2016 08:05:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <8e0bc53c8a934f58973923aea2c8998b@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Tue, 7 Jun 2016 18:05:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201606031616.14451.davemgarrett@gmail.com> <1612869.mrh4f7qht5@pintsize.usersys.redhat.com> <201606061453.53336.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C9D3F0@uxcn10-5.UoA.auckland.ac.nz> <19D9A152-3801-44DA-ADF0-345011EDF54D@gmail.com> <8e0bc53c8a934f58973923aea2c8998b@usma1ex-dag1mb1.msg.corp.akamai.com> To: Rich Salz X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2016 15:05:55 -0000 > On 7 Jun 2016, at 5:47 PM, Salz, Rich wrote: >=20 >> I=E2=80=99m not sure this helps.=20 >=20 > I'm pretty sure it wouldn't help at all, for the reasons you list. Which isn=E2=80=99t to say it=E2=80=99s not worth doing. I=E2=80=99d = love to test my implementation against a test suite rather than just = making sure it=E2=80=99s working with the five most popular browsers. It=E2=80=99s just that it won=E2=80=99t solve this particular problem. Yoav= From nobody Tue Jun 7 10:33:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A6E12D73B for ; Tue, 7 Jun 2016 10:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.328 X-Spam-Level: X-Spam-Status: No, score=-8.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HO-46Y86c2e0 for ; Tue, 7 Jun 2016 10:33:53 -0700 (PDT) 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 1913F12D5D1 for ; Tue, 7 Jun 2016 10:33:53 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 48053811DF; Tue, 7 Jun 2016 17:33:52 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-122.brq.redhat.com [10.34.0.122]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u57HXoQc011238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jun 2016 13:33:51 -0400 From: Hubert Kario To: tls@ietf.org Date: Tue, 07 Jun 2016 19:33:39 +0200 Message-ID: <4418055.GXTqvqFNm1@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.11-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <19D9A152-3801-44DA-ADF0-345011EDF54D@gmail.com> References: <19D9A152-3801-44DA-ADF0-345011EDF54D@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart13205527.zGqXmMRM9P"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 07 Jun 2016 17:33:52 +0000 (UTC) Archived-At: Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2016 17:33:55 -0000 --nextPart13205527.zGqXmMRM9P Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 07 June 2016 17:36:01 Yoav Nir wrote: > I=E2=80=99m not sure this helps. >=20 > I=E2=80=99ve never installed a server that is version intolerant. TLS= stacks > from OpenSSL, Microsoft,=20 are you sure about that Microsoft part? there is quite a long thread on the filezilla forums about TLS version=20= tolerance in IIS: https://forum.filezilla-project.org/viewtopic.php?f=3D2&t=3D27898 > Java, and most any implementation we can > name have been version tolerant forever. tls version intolerance is only one thing, then we have: * old-ish Java is intolerant of 2048 bit DH key share * many versions of OpenSSL are intolerant to very big Client Hello=20 messages (over ~1500 bytes) * old-ish IIS is intolerant to placing RC4 ciphersuites very low in=20= order and so on... > Certainly none of us can > name any implementation that at any point had a version out that was > tolerant (or implementing) TLS 1.2 but intolerant of TLS 1.3. I don't know for sure what ebay.com is running, but it certainly is TLS= =20 1.3 intolerant tls_prober[1] identifies it at Microsoft IIS 7.5 > And these are the same implementations we=E2=80=99re likely to partic= ipate in > a bakeoff or run the suite we create in the hackathon. if bugs get fixed, then we have achieved something 1 - https://github.com/WestpointLtd/tls_prober > Yoav >=20 > > On 7 Jun 2016, at 5:22 PM, Kyle Rose wrote: > >=20 > > I'm a big fan of the idea of a very strict qualification suite, as > > well, to try to head off some of these problems before (faulty) > > implementations proliferate. > >=20 > > Hackathon? > >=20 > > Kyle > >=20 > > On Jun 7, 2016 2:00 AM, "Peter Gutmann" > > wrote:>=20 > > Dave Garrett > writes: > > >Also, as with any new system, we now have the ability to loudly > > >stress to TLS 1.3+ implementers to not screw it up and test for > > >future-proofing this time around. > >=20 > > I think that's the main contribution of a new mechanism, it doesn't= > > really matter whether it's communicated as a single value, a list, > > or interpretive dance, the main thing is that there needs to be a > > single location where the version is given (not multiple locations > > that can disagree with each other as for TLS < 1.3), and the spec > > should include a pseudocode algorithm for dealing with the version > > data rather than just "implementations should accept things that > > look about right". > >=20 > > Peter. > > _______________________________________________ > > 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 =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 --nextPart13205527.zGqXmMRM9P 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 iQIcBAABCgAGBQJXVwVzAAoJEJKo0bgB0vX15/sP/RZulojErEIASbAt4GPzzywv RibBA7j6paSxZG7IwUD91+BTsgJuDDcF7ZfsZbHePKKHz4iNko9VgO7RzhCOOiMy 3IrfpUy+j9aX/1DmWLTlhsY4F/mruMXGhocipS7ttIPqkjV55/YwH+ejxUXvFYtJ blK1V6ulMnYx5DGOs+ecY3jUOmR/EWBvbq9Pye9iG1G8NKkgT3+DFAATXyheYpz5 IzzSh6O2z0Mm/0tlTZCtKp6asdb/5ltEffTTfvi1E+ip8QbnWXGMIZHcLNS1eaqO fKY0k4nzjYuCpkoKfXJD3AmqGeoe1L9BTJEmSCUTJ4ZQgSdkDDzZGqTBUYYZlpVH tJNjLH1m5wbwfNz5vaRsX2WC4lBUxuDnJ4OL/MWPdQ0VOACFAfY37+ziqi1Ve4dU EdSjM7EAi1KiYcb5qdDs7sfmw5slyJvaruslaXstMbb0ho+pwy0dc52H7+5vLUlv RkN/oeW9gNzkrzopNwZJYapo6b4wXMStIBQl9CUiXF5rwnxKZxP4npnkwQIYF9DQ UlgGT3SYvUgOZeyXo3fOW/ux8JCPKsZlEaeUEw29Us2/R+eEBZcNl0FFPNR+XOli 3VxMeu1h3pk5wKHibzetz2R9ESUouFb3E+YTFOcn/PyV7J1Bhl3xs4Ej2/yPuFrc KWYyzH8o4QuSplVndOOL =dXmr -----END PGP SIGNATURE----- --nextPart13205527.zGqXmMRM9P-- From nobody Tue Jun 7 12:58:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A89A12D1E7 for ; Tue, 7 Jun 2016 12:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SZiXZdX3vWe for ; Tue, 7 Jun 2016 12:58:14 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010: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 2E08C12D0A8 for ; Tue, 7 Jun 2016 12:58:14 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id u74so15259141lff.2 for ; Tue, 07 Jun 2016 12:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zPHJKnF0g3i2uAndKFjCQdtGyDtTYFms88SWtozbFTc=; b=Ph+0IWY1We5ar6zNfwE27DK/8Zj4///vrbwZCMTt5zKiMeXn9jwxKVklZAm5PRqZqO G3ao2xpokmOiowN7bG+UsYScpvkVra8K9tLXZo2Usns7TjPdLtNmGIcCOg7Kqqo+QOP0 HazqnjFlq6mn0zSQ8hpIbHlzshEeGSusOtpgYWSVBCZujzwO6WaPq2G6OixMvM5N/ioi Bb60vQwV3YiR0lr0BLmDq/Evp7P7vioiS3ZLQSTbsxyR6rN/d7ortn/BqSCCTYCrn5WL q0gN89Hoq+rH+hdwrZgC0q8FtVAFEKcwBfiFlQR96iaxv6FKyr/xpqEWMV3x4hS+7/9D dY8w== 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; bh=zPHJKnF0g3i2uAndKFjCQdtGyDtTYFms88SWtozbFTc=; b=iXA//aZDTvihzyz+LCG2eKtt8h0c62cwRU8wa9SR7zO/6emp57TXKcOqebTXrZylJ/ cRtIoXr+gqOM78o+BKB2fn8j1oe/ROtDzyx72ueWy1W+W9obLHOp8RHqUiqRh24l2I3s kAHkaj4s9S4wLFB1hTZexgJPkE4B5LkDX5JbqOCQJK2pX6GDaiUj9qNGkdz/tqxx9W8H UUJSJoNHLGhkMG5/z82Rm+U4BYwEckku1mrxJLH/8GFafXL7E8tpm5B39gncuJFeGpK0 Ki4O1LFmS4DsynaOANInPzZ9RrYhoEEkZxzysK5NI/Jm6FEMo3hmUU4WqKMDxoiRL9U5 o6Nw== X-Gm-Message-State: ALyK8tL7aLoH89wuTmZM3HpEE9InV13McYEDQlwBbGONRlX3eEAmV6UiwGic5wUohdvf2gHiTRSG0RIYWYn+Fw== X-Received: by 10.25.142.16 with SMTP id q16mr2821917lfd.53.1465329492054; Tue, 07 Jun 2016 12:58:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.153.135 with HTTP; Tue, 7 Jun 2016 12:57:32 -0700 (PDT) In-Reply-To: <3372929.xMFAkkVyhb@pintsize.usersys.redhat.com> References: <20160606171459.20797.7839.idtracker@ietfa.amsl.com> <3372929.xMFAkkVyhb@pintsize.usersys.redhat.com> From: Ted Lemon Date: Tue, 7 Jun 2016 15:57:32 -0400 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=001a11401682da63800534b59bf7 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Fwd: I-D Action: draft-lemon-tls-blocking-alert-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2016 19:58:16 -0000 --001a11401682da63800534b59bf7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The point of the different result codes is to give the end-user some basis for figuring out why they didn't get to the site. "Malicious site" is different than "policy violation." A malicious site is a site that serves malware, or does phishing, or typosquatting, or something like that. Policy violation could be "no facebook during business hours." Policies are typically under user control, so being able to know that you can do something to address the problem is key. The difference between "captive portal" and "user needs to check account status" is that in the one case, you have no (anticipated) business relationship with the operator of the network, whereas in the case of account status, you do. Or in any case, the network is claiming you do. So what the user would be expected to do is different--in the case of a captive portal, they might have to use some out-of-band mechanism to discover the URL they should visit to sign up, whereas in the case of a relationship with an ISP, they already presumably know the ISP's web site, and hopefully have a secure URL they can use to access it. Of course we can't do anything about that, and there is some security exposure in the case, for example, that they have an HTTP URL and an attacker wants to trick them into using it. Ideally the ISP would already have asserted that it only is accessible through TLS, and the browser would already have cached that. On Tue, Jun 7, 2016 at 5:55 AM, Hubert Kario wrote: > On Monday 06 June 2016 13:21:12 Ted Lemon wrote: > > I've posted a new document to the datatracker that adds some TLS alert > > codes that can be sent to indicate that a particular TLS request has > > been blocked by the network. This attempts to address the problem > > of notifying the user of what went wrong when a site is blocked, > > without creating a channel that can be used by a hostile network to > > attack a user. > > why separate malicious_site and policy_violation? Why not provide just a > single administratively_prohibited? I don't see a difference to the > user, in both cases the site will remain unavailable when retrying > connection and in both cases if the user thinks it's a mistake he or she > will need to contact the network administrator. > > I don't understand the account_attention_* alerts. What account does the > user need to log in? In what scenarios would they be used? How is it > different from the captive_portal? > -- > 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 --001a11401682da63800534b59bf7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The point of the different result codes is to give the end= -user some basis for figuring out why they didn't get to the site. =C2= =A0 "Malicious site" is different than "policy violation.&qu= ot; =C2=A0 A malicious site is a site that serves malware, or does phishing= , or typosquatting, or something like that. =C2=A0 Policy violation could b= e "no facebook during business hours." =C2=A0 Policies are typica= lly under user control, so being able to know that you can do something to = address the problem is key.

The difference between "= ;captive portal" and "user needs to check account status" is= that in the one case, you have no (anticipated) business relationship with= the operator of the network, whereas in the case of account status, you do= . =C2=A0 Or in any case, the network is claiming you do. =C2=A0 So what the= user would be expected to do is different--in the case of a captive portal= , they might have to use some out-of-band mechanism to discover the URL the= y should visit to sign up, whereas in the case of a relationship with an IS= P, they already presumably know the ISP's web site, and hopefully have = a secure URL they can use to access it.

Of course = we can't do anything about that, and there is some security exposure in= the case, for example, that they have an HTTP URL and an attacker wants to= trick them into using it. =C2=A0 Ideally the ISP would already have assert= ed that it only is accessible through TLS, and the browser would already ha= ve cached that.

On Tue, Jun 7, 2016 at 5:55 AM, Hubert Kario &l= t;hkario@redhat.com<= /a>> wrote:
On= Monday 06 June 2016 13:21:12 Ted Lemon wrote:
> I've posted a new document to the datatracker that adds some TLS a= lert
> codes that can be sent to indicate that a particular TLS request has > been blocked by the network.=C2=A0 =C2=A0This attempts to address the = problem
> of notifying the user of what went wrong when a site is blocked,
> without creating a channel that can be used by a hostile network to > attack a user.

why separate malicious_site and policy_violation? Why not provide ju= st a
single administratively_prohibited? I don't see a difference to the
user, in both cases the site will remain unavailable when retrying
connection and in both cases if the user thinks it's a mistake he or sh= e
will need to contact the network administrator.

I don't understand the account_attention_* alerts. What account does th= e
user need to log in? In what scenarios would they be used? How is it
different from the captive_portal?
--
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

--001a11401682da63800534b59bf7-- From nobody Tue Jun 7 13:05:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE6E12B02A for ; Tue, 7 Jun 2016 13:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOKZmBmD8k_V for ; Tue, 7 Jun 2016 13:05:21 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 9413A12D14D for ; Tue, 7 Jun 2016 12:55:59 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id z123so105523090itg.0 for ; Tue, 07 Jun 2016 12:55:59 -0700 (PDT) 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; bh=Jm53TEr7NpJ4gSMfj/OHuX6Q53fPyABLVwBH4nQN3S4=; b=hm+RywB4VnQeHHIBJAE7e8LKSpHioUr64JcScdjYQGViccPmxFlYBSlqCQpvOkwxlf y3V5AVf2lOo5V0mDtTzgOc0RH615bD4ssQMre0F7VN0wPsSb+UNAPPV/qTsPECwwcfuv 8W3Zs5YCQDMTUNOZ5ldJ+Bl9IMF1Hyrip5XsBxdq67/G7JbePQN00fySwLH9jAky6n96 JbtVrOviOMPWNB8xTwUvbGbEvSf9DLCCq7fGFlYNit9ikeI4aClcs3FbEC7Ufy5yIg2E Z8P3IZ3XmWWRD+HElKrVhr+kIiWHeGEHq9ztPLSvboyUfNY3tv2hSt2bQLrnhe3Pha9l R+pA== 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; bh=Jm53TEr7NpJ4gSMfj/OHuX6Q53fPyABLVwBH4nQN3S4=; b=h8jjxRm+2NfX/EILpaA2NN5Fex5aXtSm1Gk3l//eUsz4+wONXSvnB4zelMjl4S16HA NYo8rfUpfOd7Pnt6ifxu8iN8D0TyFd4dQtmGoBZB7Jrlfhtg40SboKQXJLfr9ribDEX3 AqLnrU7yJSP0NAiLqRL4+6XfvnvR8sTipVGLVw0LbC0Pvzv+AWasWegC9vFHM7/c8sbG gaVdXYIeIUpBWxjozzGWvMrMg6MQLSKgtfOFbdAeA+JyU2uXn/3qWfZ6QpiY9+Bqaq5W zMCNrAgmHFwNIDUQiHu4Pfl0GG/rVErzFuoHqIiovFgxqvMJXxPqRjMbDAetIH+e8Xcp +xVA== X-Gm-Message-State: ALyK8tL1/RlIt03TsAvetXrMME6qQgFf3qR0HrXPZSyw0ig7JfMidwUX737MyBHuF7r5j+VAGzUdNIfr0mDLgw== MIME-Version: 1.0 X-Received: by 10.107.10.206 with SMTP id 75mr2449181iok.51.1465329358875; Tue, 07 Jun 2016 12:55:58 -0700 (PDT) Received: by 10.36.137.87 with HTTP; Tue, 7 Jun 2016 12:55:58 -0700 (PDT) In-Reply-To: References: <20160606171459.20797.7839.idtracker@ietfa.amsl.com> Date: Tue, 7 Jun 2016 09:55:58 -1000 Message-ID: From: Brian Smith To: Ted Lemon Content-Type: multipart/alternative; boundary=001a113f89b4ea51ff0534b593a3 Archived-At: Cc: "" Subject: Re: [TLS] Fwd: I-D Action: draft-lemon-tls-blocking-alert-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2016 20:05:22 -0000 --001a113f89b4ea51ff0534b593a3 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 6, 2016 at 7:21 AM, Ted Lemon wrote: > I've posted a new document to the datatracker that adds some TLS alert > codes that can be sent to indicate that a particular TLS request has been > blocked by the network. This attempts to address the problem of notifying > the user of what went wrong when a site is blocked, without creating a > channel that can be used by a hostile network to attack a user. > This is a bad idea in general, and we shouldn't do things like this. Standardizing and implementing things like this signals, politically, that we accept and even encourage censorship like we see in China and many other places already in the world. That, on its own, makes this a non-starter. The inconvenience, confusion, and unreliability of current methods of (not) notifying the user about the filtering is a strong disincentive towards people thinking about deploying filtering that is abusive. Perhaps there is some kind of filtering that isn't abusive, but IMO the gain from improving that doesn't outweigh any loss, politically or otherwise, from, intentionally or unintentionally supporting the abusive filtering. Cheers, Brian -- https://briansmith.org/ --001a113f89b4ea51ff0534b593a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 6, 2016 at 7:21 AM, Ted Lemon <mellon@fugue.com> wrot= e:
I've po= sted a new document to the datatracker that adds some TLS alert codes that = can be sent to indicate that a particular TLS request has been blocked by t= he network. =C2=A0 This attempts to address the problem of notifying the us= er of what went wrong when a site is blocked, without creating a channel th= at can be used by a hostile network to attack a user.

This is a bad idea in general, and = we shouldn't do things like this.

<= /div>
Standardizing and implementing things like = this signals, politically, that we accept and even encourage censorship lik= e we see in China and many other places already in the world. That, on its = own, makes this a non-starter.

The inconvenience, confusion, and unreliability of= current methods of (not) notifying the user about the filtering is a stron= g disincentive towards people thinking about deploying filtering that is ab= usive.

Perhaps there is some kind of filtering that isn't abusive, but IMO th= e gain from improving that doesn't outweigh any loss, politically or ot= herwise, from, intentionally or unintentionally supporting the abusive filt= ering.

Cheers,
Brian
--
--001a113f89b4ea51ff0534b593a3-- From nobody Tue Jun 7 13:17:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BFF12D550 for ; Tue, 7 Jun 2016 13:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnWz4gYHTHud for ; Tue, 7 Jun 2016 13:17:44 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010: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 8FA5D12B026 for ; Tue, 7 Jun 2016 13:17:43 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id u74so15574954lff.2 for ; Tue, 07 Jun 2016 13:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HaWhZ7Xhcqu2KfVAatgdwTL0jLC4xs34+LDCoWmhAB8=; b=sKVpjl9Eu3trgOXqwXd5rozdlPHbsCUJCTOsGuQ/Z3MyZbnVWUijPfKtFM0a0pGWlU oqHCRHxq1Z1risKMXAzpv7fFoRvlpqFEYCUWMAKVmHoGYV74GZjlZPOE4e+NvU3iIKwt HxsGsSHRQyk0qp9E9OoLZcVOTCGIg8hGJJ4QnthruWiAHOhxo/dSGQv5Ky0vMCq2/Gl+ Db7z7UnUiCuq1S3eFedcLmrRBsirSwCyZLL/VsvHlrXlEOnch0wMTFb2+VzI0ZbglcZL nxD3JOT/4a6Y5M+2n1CxG7GxjrK0RK5cLikQPj+CFqWHRTvwL9+xBCfbMKuKirlDMmly Ls1g== 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; bh=HaWhZ7Xhcqu2KfVAatgdwTL0jLC4xs34+LDCoWmhAB8=; b=f+TfSe/C0xopsMUYtVKuxRiziqOZ7q5qnZPo2g8uK87QP8cncAepg4RMgUTWSSXZns 7iLF8xQFLOscLP0mwWtZ4wVezUJGVvkuR5gR7RECJ1P6TwCf8xQE0Y7BOefhiTXzAfe4 +kPIQpQNpTNxTp7SXBFEoClzC2yC/0S/RMR1goPqxu8FeScNfL+oez6vtjZDKAqFjOc9 7RuZTRReP6QFztDbzgHQ+dlCVmq2cSO63yBD8U5DQDj8rmsQbcpojML5I5xqfNO5YTDO Y4ftzM0x9tLkLF31p/RW9Q1obpgsRFgjsBwWMBco/AZII8CQYpPfZCOMiOu/P8oL3sFI lwKQ== X-Gm-Message-State: ALyK8tINk1AWdZ0NFV65HVptUTKKjHy/yUoT49P5tLJmznZdKjAfif1N586JosUoWAeIGrDKYdMPVSFPhJezJA== X-Received: by 10.25.142.16 with SMTP id q16mr2837704lfd.53.1465330661461; Tue, 07 Jun 2016 13:17:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.153.135 with HTTP; Tue, 7 Jun 2016 13:17:01 -0700 (PDT) In-Reply-To: References: <20160606171459.20797.7839.idtracker@ietfa.amsl.com> From: Ted Lemon Date: Tue, 7 Jun 2016 16:17:01 -0400 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=001a114016828e1cfc0534b5e1be Archived-At: Cc: "" Subject: Re: [TLS] Fwd: I-D Action: draft-lemon-tls-blocking-alert-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2016 20:17:46 -0000 --001a114016828e1cfc0534b5e1be Content-Type: text/plain; charset=UTF-8 Brian, I totally sympathize with that, but this isn't really the 451 use case, much as it seems to resemble it. In reality, there are actual risks that people want to be protected from, and services that offer to protect them from those risks. Malware and phishing are obvious examples--older folks with diminished capacity who aren't protected from phishing attacks can lose everything, and malware is a serious problem. Some families want to protect their kids from contact with people they consider unsuitable, and this is a reasonable thing for them to want to do. It's also useful to be able to notify the end user when their connection is in a state where they won't be able to get access, and there is something they can do to change that. The more web sites that are properly protected by TLS, the harder it becomes to do this. We can't offer network operators, who are potentially attackers, a way to send content to the user. A result code with no operator-configurable content is a good way out of that problem. Furthermore, transparency is useful. The IETF recently published an RFC documenting the 451 result code precisely because it aids in transparency. The IETF didn't signal, politically, that the IETF is in favor of censorship. When you get this result code, you know what happened. That's important: if you don't know that your connection was censored, you might think it's just a network problem, and not realize that you need to take action at layer 9 to correct the problem. These result codes accomplish the same thing, in a finer-grained way, for TLS connections. Current methods aren't at all unreliable. It's no problem to block web sites that fall into classes the end user wants blocked, or that are blocked for policy reasons. The problem is that we need to inform the end user as to what happened. Right now we have two options for doing that. Either we require the user to install and trust a cert, or we require them to click through security warnings. Both of these options are extremely damaging from a security perspective. End-to-end TLS encryption is really important for protecting sensitive communication. Trusting your ISP to MiTM your communication is a dumb idea. But ISPs won't have any trouble at all convincing users to do this. Similarly, training your end users to click through invalid cert warnings will also work. But it's a terrible idea to solve the problem that way. The point being that right now all the standards-compliant ways of being transparent about this are bad from a security perspective. I don't think the IETF should take a position on whether this is a good idea, but if the IETF consensus is not to add these result codes, I think that would be a worse outcome than publishing them. On Tue, Jun 7, 2016 at 3:55 PM, Brian Smith wrote: > On Mon, Jun 6, 2016 at 7:21 AM, Ted Lemon wrote: > >> I've posted a new document to the datatracker that adds some TLS alert >> codes that can be sent to indicate that a particular TLS request has been >> blocked by the network. This attempts to address the problem of notifying >> the user of what went wrong when a site is blocked, without creating a >> channel that can be used by a hostile network to attack a user. >> > > This is a bad idea in general, and we shouldn't do things like this. > > Standardizing and implementing things like this signals, politically, that > we accept and even encourage censorship like we see in China and many other > places already in the world. That, on its own, makes this a non-starter. > > The inconvenience, confusion, and unreliability of current methods of > (not) notifying the user about the filtering is a strong disincentive > towards people thinking about deploying filtering that is abusive. > > Perhaps there is some kind of filtering that isn't abusive, but IMO the > gain from improving that doesn't outweigh any loss, politically or > otherwise, from, intentionally or unintentionally supporting the abusive > filtering. > > Cheers, > Brian > -- > https://briansmith.org/ > > --001a114016828e1cfc0534b5e1be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Brian, I totally sympathize with that, but this isn't = really the 451 use case, much as it seems to resemble it. =C2=A0 In reality= , there are actual risks that people want to be protected from, and service= s that offer to protect them from those risks. =C2=A0 Malware and phishing = are obvious examples--older folks with diminished capacity who aren't p= rotected from phishing attacks can lose everything, and malware is a seriou= s problem. =C2=A0 Some families want to protect their kids from contact wit= h people they consider unsuitable, and this is a reasonable thing for them = to want to do.

It's also useful to be able to notify= the end user when their connection is in a state where they won't be a= ble to get access, and there is something they can do to change that. =C2= =A0 The more web sites that are properly protected by TLS, the harder it be= comes to do this. =C2=A0 We can't offer network operators, who are pote= ntially attackers, a way to send content to the user. =C2=A0 A result code = with no operator-configurable content is a good way out of that problem.

Furthermore, transparency is useful. =C2=A0 The IETF r= ecently published an RFC documenting the 451 result code precisely because = it aids in transparency.=C2=A0 The IETF didn't signal, politically, tha= t the IETF is in favor of censorship. =C2=A0 When you get this result code,= you know what happened. =C2=A0 That's important: if you don't know= that your connection was censored, you might think it's just a network= problem, and not realize that you need to take action at layer 9 to correc= t the problem. =C2=A0 These result codes accomplish the same thing, in a fi= ner-grained way, for TLS connections.

Current meth= ods aren't at all unreliable. =C2=A0 It's no problem to block web s= ites that fall into classes the end user wants blocked, or that are blocked= for policy reasons. =C2=A0 The problem is that we need to inform the end u= ser as to what happened. =C2=A0 Right now we have two options for doing tha= t. =C2=A0 Either we require the user to install and trust a cert, or we req= uire them to click through security warnings.

Both= of these options are extremely damaging from a security perspective. =C2= =A0 End-to-end TLS encryption is really important for protecting sensitive = communication. =C2=A0 Trusting your ISP to MiTM your communication is a dum= b idea. =C2=A0 But ISPs won't have any trouble at all convincing users = to do this.

Similarly, training your end users to click= through invalid cert warnings will also work. =C2=A0 But it's a terrib= le idea to solve the problem that way.

The point b= eing that right now all the standards-compliant ways of being transparent a= bout this are bad from a security perspective. =C2=A0 I don't think the= IETF should take a position on whether this is a good idea, but if the IET= F consensus is not to add these result codes, I think that would be a worse= outcome than publishing them.


On Tue, Jun 7, 2016 at 3:55 PM, Bri= an Smith <brian@briansmith.org> wrote:
On Mon, Jun 6, 2016 at 7:21 AM, Ted Lemon <mel= lon@fugue.com> wrote:
I've posted a new document to the datatracker tha= t adds some TLS alert codes that can be sent to indicate that a particular = TLS request has been blocked by the network. =C2=A0 This attempts to addres= s the problem of notifying the user of what went wrong when a site is block= ed, without creating a channel that can be used by a hostile network to att= ack a user.

This is a bad idea in general, and we shouldn't do things like thi= s.

Sta= ndardizing and implementing things like this signals, politically, that we = accept and even encourage censorship like we see in China and many other pl= aces already in the world. That, on its own, makes this a non-starter.

The inconv= enience, confusion, and unreliability of current methods of (not) notifying= the user about the filtering is a strong disincentive towards people think= ing about deploying filtering that is abusive.

Perhaps there is some kind of filt= ering that isn't abusive, but IMO the gain from improving that doesn= 9;t outweigh any loss, politically or otherwise, from, intentionally or uni= ntentionally supporting the abusive filtering.

Ch= eers,
Brian
-= -

--001a114016828e1cfc0534b5e1be-- From nobody Tue Jun 7 14:06:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBA312D1A5 for ; Tue, 7 Jun 2016 14:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4E_9H5i6jRz for ; Tue, 7 Jun 2016 14:06:29 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c: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 07C8512D10F for ; Tue, 7 Jun 2016 14:06:29 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id n184so154443396wmn.1 for ; Tue, 07 Jun 2016 14:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=H1CIGxMNpw6h/4M/Po68qgMyVo5+WreeiNy/6Uk7ZUs=; b=wctva9noOka8CYIoDwaI/uoN8+hqDREYUj2F7By1IpI8RzzF7/o2BgF9u/yN0WBZm0 0WcjQ3z6sxfDRRChQ55r7K+q6YS89XIbng3+UJ7/mcsxIZemSM5LyJy3ZTm9gKGkPRuO 4VCs3fjqULCZA2rNjGAJvUal8dJSt9xy7nsVOAEgFw4SYrK4YQGdYM3zJCUgzGZr4t0E jw5FugggZAKoQ0MHyPF/Gu/nJ8Jg8dXecm/6xOzfzLSCvvI46MLQW1HXmik3Xn44knR+ 7NBg1VT9/yCn/4YRJnSuCGDr5nSpmT4R83A7wX4j3/ghZFKHL0vx79NLuGS6cTnNTRGG GQLg== 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:from:in-reply-to:date:cc :message-id:references:to; bh=H1CIGxMNpw6h/4M/Po68qgMyVo5+WreeiNy/6Uk7ZUs=; b=QB6eBVlD59m0irFKx47awZbaQyat+iBIGMF8YyKw/9corwm0x+n5AIqV6lVqCJj0Tg p3h2RvGaUdNf+Xm+C0f8LKtlll02CRe81tXisvfi6WqmpYHjzpd6dyDxdHrO4eQ78toU NoB4MaAenCYm3MVfWl9sBPzpiLJTOYJr8XYXoJnJkhAZ5b+csLxqy4rclKg9C0/SQX3S 7xfP0CqVSSbuYSYJwdsGP1TCP2+fIuZZDgBA2cWBVXhIXa8t+KXNeHUzxmi0bgQFjnP6 472fwFo18LF7FksGkqusCp5pQQ2N004EdNWnP5yJQkQ1C+TdDDWv12tS72IDklz1COgr ztGg== X-Gm-Message-State: ALyK8tJXsB39RFQ2B/7EqLHcWpGpSfeD5TKgHOkOvukwiQLwpwXUSG20gwL1X4TFxT5Ssw== X-Received: by 10.195.8.40 with SMTP id dh8mr1323528wjd.178.1465333587345; Tue, 07 Jun 2016 14:06:27 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id f186sm21225961wma.13.2016.06.07.14.06.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Jun 2016 14:06:26 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F61D2F9D-80ED-43E6-8963-E47EFC35BC63"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Yoav Nir In-Reply-To: <4418055.GXTqvqFNm1@pintsize.usersys.redhat.com> Date: Wed, 8 Jun 2016 00:06:23 +0300 Message-Id: <60729080-E56E-41D5-AAB0-FAD46FCE1C00@gmail.com> References: <19D9A152-3801-44DA-ADF0-345011EDF54D@gmail.com> <4418055.GXTqvqFNm1@pintsize.usersys.redhat.com> To: Hubert Kario X-Mailer: Apple Mail (2.3124) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2016 21:06:30 -0000 --Apple-Mail=_F61D2F9D-80ED-43E6-8963-E47EFC35BC63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 7 Jun 2016, at 8:33 PM, Hubert Kario wrote: >=20 > On Tuesday 07 June 2016 17:36:01 Yoav Nir wrote: >> I=E2=80=99m not sure this helps. >>=20 >> I=E2=80=99ve never installed a server that is version intolerant. TLS = stacks >> from OpenSSL, Microsoft, >=20 > are you sure about that Microsoft part? >=20 > there is quite a long thread on the filezilla forums about TLS version > tolerance in IIS: > https://forum.filezilla-project.org/viewtopic.php?f=3D2&t=3D27898 That=E2=80=99s surprising. The last time I tested with an IIS servers it was Windows Server 2003 = and 2008. They did not support TLS 1.2, so I wanted to check if they = could tolerate a TLS 1.2 ClientHello. They did. Of course, they replied = with TLS 1.0, but that was expected. It=E2=80=99s strange that this behavior would degrade for much newer = versions of Windows that came out at a time where several browsers were = already offering TLS 1.2. I wonder if it=E2=80=99s just the FTP or also = IIS. Yoav --Apple-Mail=_F61D2F9D-80ED-43E6-8963-E47EFC35BC63 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----- iQEcBAEBCAAGBQJXVzdQAAoJECXR4BOacZZU47QH/j3CB2/xrO3lorMpgHtNFfkI UlNYHXI/jkwRwLKpC6L59e2NmaWBRCsu6rLJoqm3GpO+dI/eqpS5VLqfgWYlV8zH t+Jp3gyh9NAMdG0nrziEw5lQiyrfTvzIPsMojXsLIiE9fRHvJuCsnjad8dTNzXfW be9Y9IMmZvQnIWf4pfzsOv1+uHzskBFq/rHfrvvNkzCU/DJod+Lu7AbdejXwBuSC U13jqBLe/pi3b5wUfyM7I+oFlRwm81nLeMZdHG0krriX6bbUxD4Re6Sj+FmEzJh2 0Mq5rztfCXl79N0Q8c0jeuuMMtRzHajAsVGLJHclZWpDFkD+JuTtOE5ki2OTLug= =pGwT -----END PGP SIGNATURE----- --Apple-Mail=_F61D2F9D-80ED-43E6-8963-E47EFC35BC63-- From nobody Tue Jun 7 14:08:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B9612D5F0 for ; Tue, 7 Jun 2016 14:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BblCe9qEfu8H for ; Tue, 7 Jun 2016 14:08:11 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 44F0512D168 for ; Tue, 7 Jun 2016 14:08:11 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id h62so46580862itb.1 for ; Tue, 07 Jun 2016 14:08:11 -0700 (PDT) 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 :cc; bh=BdLjQzCWnu+0ZKMS/pWB1jMdwDNhYDv1t9mfaHkOeVc=; b=gSct2Ljsr8lzqz0DyGKeoKZba9aEBEPakIfyAI/yIb6AHW5TSCWal36ZRf7nL0/s4E rALc2fxkxwYE4dmYPYMjuZjP+cwZA531GlSuXfUt1nmGJTjEKOtOcaxGHs+Ld1Jy5/yx thmRN4qhjpzkeUfut9sIad13rHc/3G+Eyo880= 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:cc; bh=BdLjQzCWnu+0ZKMS/pWB1jMdwDNhYDv1t9mfaHkOeVc=; b=iIpXbB/Q53N2ULDnLHIPn+g+TJmoKaucBVPIvKDzj0Nh8vyLMpcn1P5AlikKQCJy+c JspD/nX+bHziQh/BmVdyM90xQ71jEVInNsLLvcU20Gnw6eG0l5sWpUYvlzf+av2C6R+5 mwqvfEjAYx3bMwQb+BRrLRmtdHB2i1/zwGYgwxIUlcwkiytlDUKNSYq16SXKitTeSZcr gVGvXBrhmFrL/leId9R6Yqkeu2dUFXLzfybMnohHBHUvW+JcAqJsI6z6WEEgf/GPBS4K TYbAIeqMKb1LwDWqXUTScTgaRQdD7NDsa2dlfc9MfoahPjwH0foElfWjae4Pt2IT7eDK ZGqg== X-Gm-Message-State: ALyK8tL9wQl2izKNjWLh0q4Vq9+gwxTrxp9IktHTXDr67aOt8B9ToTVaGsTG0HYR+8LVy8QfoZE2s3Kcq/5hCFVG X-Received: by 10.36.61.202 with SMTP id n193mr7699278itn.92.1465333690423; Tue, 07 Jun 2016 14:08:10 -0700 (PDT) MIME-Version: 1.0 References: <19D9A152-3801-44DA-ADF0-345011EDF54D@gmail.com> <4418055.GXTqvqFNm1@pintsize.usersys.redhat.com> <60729080-E56E-41D5-AAB0-FAD46FCE1C00@gmail.com> In-Reply-To: <60729080-E56E-41D5-AAB0-FAD46FCE1C00@gmail.com> From: David Benjamin Date: Tue, 07 Jun 2016 21:08:00 +0000 Message-ID: To: Yoav Nir , Hubert Kario Content-Type: multipart/alternative; boundary=001a1145bb4618b6d80534b6963c Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2016 21:08:13 -0000 --001a1145bb4618b6d80534b6963c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 7, 2016 at 5:06 PM Yoav Nir wrote: > > > On 7 Jun 2016, at 8:33 PM, Hubert Kario wrote: > > > > On Tuesday 07 June 2016 17:36:01 Yoav Nir wrote: > >> I=E2=80=99m not sure this helps. > >> > >> I=E2=80=99ve never installed a server that is version intolerant. TLS = stacks > >> from OpenSSL, Microsoft, > > > > are you sure about that Microsoft part? > > > > there is quite a long thread on the filezilla forums about TLS version > > tolerance in IIS: > > https://forum.filezilla-project.org/viewtopic.php?f=3D2&t=3D27898 > > That=E2=80=99s surprising. > > The last time I tested with an IIS servers it was Windows Server 2003 and > 2008. They did not support TLS 1.2, so I wanted to check if they could > tolerate a TLS 1.2 ClientHello. They did. Of course, they replied with TL= S > 1.0, but that was expected. > > It=E2=80=99s strange that this behavior would degrade for much newer vers= ions of > Windows that came out at a time where several browsers were already > offering TLS 1.2. I wonder if it=E2=80=99s just the FTP or also IIS. > This is the first I've heard of this and I believe neither Chrome nor Firefox accept TLS 1.2 intolerance and below anymore. To my knowledge, that has successfully been driven out of the ecosystem. David --001a1145bb4618b6d80534b6963c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 7,= 2016 at 5:06 PM Yoav Nir <ynir.i= etf@gmail.com> wrote:

> On 7 Jun 2016, at 8:33 PM, Hubert Kario <hkario@redhat.com> wrote:
>
> On Tuesday 07 June 2016 17:36:01 Yoav Nir wrote:
>> I=E2=80=99m not sure this helps.
>>
>> I=E2=80=99ve never installed a server that is version intolerant. = TLS stacks
>> from OpenSSL, Microsoft,
>
> are you sure about that Microsoft part?
>
> there is quite a long thread on the filezilla forums about TLS version=
> tolerance in IIS:
> https://forum.filezilla-pr= oject.org/viewtopic.php?f=3D2&t=3D27898

That=E2=80=99s surprising.

The last time I tested with an IIS servers it was Windows Server 2003 and 2= 008. They did not support TLS 1.2, so I wanted to check if they could toler= ate a TLS 1.2 ClientHello. They did. Of course, they replied with TLS 1.0, = but that was expected.

It=E2=80=99s strange that this behavior would degrade for much newer versio= ns of Windows that came out at a time where several browsers were already o= ffering TLS 1.2. I wonder if it=E2=80=99s just the FTP or also IIS.

This is the first I've heard of this and I= believe neither Chrome nor Firefox accept TLS 1.2 intolerance and below an= ymore. To my knowledge, that has successfully been driven out of the ecosys= tem.

David
--001a1145bb4618b6d80534b6963c-- From nobody Tue Jun 7 14:14:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E3712D862 for ; Tue, 7 Jun 2016 14:14:38 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9on_na8NL_k for ; Tue, 7 Jun 2016 14:14:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0743.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::743]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FEA212D6A6 for ; Tue, 7 Jun 2016 14:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=20avoJyKcrcfyMzlBHJas3hTBFo9Q5um9z3DuZKTY9g=; b=lfxWGlEirEQxyXekP6nm7O6K+QnNO+0ZbEFbKVTAM+X6dLf+5OJjYi2livUzJJf/8rIXJwkWcyte+E226bLbhq7RURLcr4CP21fGJTL8lP9m87fOFYm8ZOouxJsC/nOM54VGDndFnhmL2vKOoBUiPTM+z/ahKYtX407PQRBYul4= Received: from BN3PR03MB1445.namprd03.prod.outlook.com (10.163.34.28) by BN3PR03MB1448.namprd03.prod.outlook.com (10.163.35.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.511.8; Tue, 7 Jun 2016 21:14:32 +0000 Received: from BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) by BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) with mapi id 15.01.0511.010; Tue, 7 Jun 2016 21:14:32 +0000 From: Andrei Popov To: David Benjamin , Yoav Nir , Hubert Kario Thread-Topic: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] Thread-Index: AQHRwIH20mYqUN6o/UO2r62mJ+MY7p/eDvwAgAAD04CAADGhgIAAO3CAgAAAdACAAACaMA== Date: Tue, 7 Jun 2016 21:14:32 +0000 Message-ID: References: <19D9A152-3801-44DA-ADF0-345011EDF54D@gmail.com> <4418055.GXTqvqFNm1@pintsize.usersys.redhat.com> <60729080-E56E-41D5-AAB0-FAD46FCE1C00@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=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:5::1d2] x-ms-office365-filtering-correlation-id: a0da8fe6-2b65-4804-0dfa-08d38f18b886 x-microsoft-exchange-diagnostics: 1; BN3PR03MB1448; 5:V9wZdDQcb5yKPLdLoOUf0coP+gmWNVf7pPKcnRTUm8+0uhiKOEylnaQzKNAD8eJRap+bYZ3K0UB4Rpq/CkHv/vbvGghmgIQkeSYMwvPkSrcswMz9LLLdJgy4NC9ge6vuMDJXmWhz+lhLhYLUIs4Zbg==; 24:FBIMKxyTaaZtjf8/eNnQyVrfW6O97/5lNizJc0B/2iFUp0WD53IRgKSP4a6fjzCLEUsTc+5g4uwIUzy6NRt27SC6oLekiG6xJ+brda4WUFo=; 7:aecbIDZ8EVvfR4eGjHjt+cz5LfOwjV8LYLCvxuDoVov+M3AsrLMuS8R27Cqueep7OQM6tEGbNBKr+QW6dOj+lZvIrxGJOjlVzvRy7t1iR5z/ygsd+C3Z6PRd9CcCS8Y0Y+YfmymrpA/qxTpSH0zn81JWHTtpnCe6ZEAZKAuWfJjp6szd5CPRd9DHVUvGopKQHpxHLP9g2PHvFmX80h2PA65WeENqknVUj/w40wS9Bz0PYuY/p/gjBkdpvvY/x9Gs x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1448; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(49104720798648)(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR03MB1448; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1448; x-forefront-prvs: 09669DB681 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(54094003)(199003)(3905003)(189002)(5003600100002)(122556002)(19617315012)(86362001)(16236675004)(16799955002)(99286002)(81156014)(8676002)(106356001)(10090500001)(2900100001)(81166006)(5002640100001)(19625215002)(8936002)(19580405001)(92566002)(77096005)(105586002)(106116001)(2950100001)(76576001)(9686002)(10400500002)(8990500004)(10290500002)(19580395003)(19609705001)(86612001)(5008740100001)(189998001)(586003)(790700001)(76176999)(3660700001)(5005710100001)(15975445007)(11100500001)(33656002)(101416001)(2906002)(102836003)(4326007)(74316001)(6116002)(97736004)(50986999)(54356999)(19300405004)(5001770100001)(87936001)(93886004)(68736007)(5004730100002)(3280700002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1448; H:BN3PR03MB1445.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:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB1445876F534D9F09882F7B3F8C5D0BN3PR03MB1445namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2016 21:14:32.6058 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1448 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2016 21:14:38 -0000 --_000_BN3PR03MB1445876F534D9F09882F7B3F8C5D0BN3PR03MB1445namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVtcGluZyB0byB0aGUgZW5kIG9mIHRoZSB0aHJlYWQsIGl0IGxvb2tzIGxpa2UgdGhpcyBpcyBh biBGVFAgaXNzdWUgdGhhdCByZXByb3Mgd2hlbiBUTFMgMS4yIGlzIG5lZ290aWF0ZWQuIE5vdCBh IFRMUyB2ZXJzaW9uIGludG9sZXJhbmNlLg0KVGhlIGNvbmNsdXNpb24gc2VlbXMgdG8gYmUgdGhh dCBodHRwczovL3N1cHBvcnQubWljcm9zb2Z0LmNvbS9lbi11cy9rYi8yODg4ODUzIHJlc29sdmVz IHRoZSBpc3N1ZSwgYnkgdXBkYXRpbmcgRlRQIGJpbmFyaWVzLg0KDQpDaGVlcnMsDQoNCkFuZHJl aQ0KDQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IERhdmlkIEJlbmphbWluDQpTZW50OiBUdWVzZGF5LCBKdW5lIDcsIDIwMTYgMjowOCBQTQ0KVG86 IFlvYXYgTmlyIDx5bmlyLmlldGZAZ21haWwuY29tPjsgSHViZXJ0IEthcmlvIDxoa2FyaW9AcmVk aGF0LmNvbT4NCkNjOiB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExTXSBbRk9SR0VEXSBS ZTogbm8gZmFsbGJhY2tzIHBsZWFzZSBbd2FzOiBEb3duZ3JhZGUgcHJvdGVjdGlvbiwgZmFsbGJh Y2tzLCBhbmQgc2VydmVyIHRpbWVdDQoNCk9uIFR1ZSwgSnVuIDcsIDIwMTYgYXQgNTowNiBQTSBZ b2F2IE5pciA8eW5pci5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eW5pci5pZXRmQGdtYWlsLmNvbT4+ IHdyb3RlOg0KDQo+IE9uIDcgSnVuIDIwMTYsIGF0IDg6MzMgUE0sIEh1YmVydCBLYXJpbyA8aGth cmlvQHJlZGhhdC5jb208bWFpbHRvOmhrYXJpb0ByZWRoYXQuY29tPj4gd3JvdGU6DQo+DQo+IE9u IFR1ZXNkYXkgMDcgSnVuZSAyMDE2IDE3OjM2OjAxIFlvYXYgTmlyIHdyb3RlOg0KPj4gSeKAmW0g bm90IHN1cmUgdGhpcyBoZWxwcy4NCj4+DQo+PiBJ4oCZdmUgbmV2ZXIgaW5zdGFsbGVkIGEgc2Vy dmVyIHRoYXQgaXMgdmVyc2lvbiBpbnRvbGVyYW50LiBUTFMgc3RhY2tzDQo+PiBmcm9tIE9wZW5T U0wsIE1pY3Jvc29mdCwNCj4NCj4gYXJlIHlvdSBzdXJlIGFib3V0IHRoYXQgTWljcm9zb2Z0IHBh cnQ/DQo+DQo+IHRoZXJlIGlzIHF1aXRlIGEgbG9uZyB0aHJlYWQgb24gdGhlIGZpbGV6aWxsYSBm b3J1bXMgYWJvdXQgVExTIHZlcnNpb24NCj4gdG9sZXJhbmNlIGluIElJUzoNCj4gaHR0cHM6Ly9m b3J1bS5maWxlemlsbGEtcHJvamVjdC5vcmcvdmlld3RvcGljLnBocD9mPTImdD0yNzg5OA0KDQpU aGF04oCZcyBzdXJwcmlzaW5nLg0KDQpUaGUgbGFzdCB0aW1lIEkgdGVzdGVkIHdpdGggYW4gSUlT IHNlcnZlcnMgaXQgd2FzIFdpbmRvd3MgU2VydmVyIDIwMDMgYW5kIDIwMDguIFRoZXkgZGlkIG5v dCBzdXBwb3J0IFRMUyAxLjIsIHNvIEkgd2FudGVkIHRvIGNoZWNrIGlmIHRoZXkgY291bGQgdG9s ZXJhdGUgYSBUTFMgMS4yIENsaWVudEhlbGxvLiBUaGV5IGRpZC4gT2YgY291cnNlLCB0aGV5IHJl cGxpZWQgd2l0aCBUTFMgMS4wLCBidXQgdGhhdCB3YXMgZXhwZWN0ZWQuDQoNCkl04oCZcyBzdHJh bmdlIHRoYXQgdGhpcyBiZWhhdmlvciB3b3VsZCBkZWdyYWRlIGZvciBtdWNoIG5ld2VyIHZlcnNp b25zIG9mIFdpbmRvd3MgdGhhdCBjYW1lIG91dCBhdCBhIHRpbWUgd2hlcmUgc2V2ZXJhbCBicm93 c2VycyB3ZXJlIGFscmVhZHkgb2ZmZXJpbmcgVExTIDEuMi4gSSB3b25kZXIgaWYgaXTigJlzIGp1 c3QgdGhlIEZUUCBvciBhbHNvIElJUy4NCg0KVGhpcyBpcyB0aGUgZmlyc3QgSSd2ZSBoZWFyZCBv ZiB0aGlzIGFuZCBJIGJlbGlldmUgbmVpdGhlciBDaHJvbWUgbm9yIEZpcmVmb3ggYWNjZXB0IFRM UyAxLjIgaW50b2xlcmFuY2UgYW5kIGJlbG93IGFueW1vcmUuIFRvIG15IGtub3dsZWRnZSwgdGhh dCBoYXMgc3VjY2Vzc2Z1bGx5IGJlZW4gZHJpdmVuIG91dCBvZiB0aGUgZWNvc3lzdGVtLg0KDQpE YXZpZA0K --_000_BN3PR03MB1445876F534D9F09882F7B3F8C5D0BN3PR03MB1445namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SnVtcGluZyB0byB0aGUgZW5kIG9mIHRo ZSB0aHJlYWQsIGl0IGxvb2tzIGxpa2UgdGhpcyBpcyBhbiBGVFAgaXNzdWUgdGhhdCByZXByb3Mg d2hlbiBUTFMgMS4yIGlzIG5lZ290aWF0ZWQuIE5vdCBhIFRMUyB2ZXJzaW9uIGludG9sZXJhbmNl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgY29uY2x1c2lvbiBzZWVtcyB0byBiZSB0aGF0DQo8YSBo cmVmPSJodHRwczovL3N1cHBvcnQubWljcm9zb2Z0LmNvbS9lbi11cy9rYi8yODg4ODUzIj5odHRw czovL3N1cHBvcnQubWljcm9zb2Z0LmNvbS9lbi11cy9rYi8yODg4ODUzPC9hPiByZXNvbHZlcyB0 aGUgaXNzdWUsIGJ5IHVwZGF0aW5nIEZUUCBiaW5hcmllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkFuZHJlaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RGF2aWQgQmVuamFtaW48YnI+DQo8Yj5TZW50 OjwvYj4gVHVlc2RheSwgSnVuZSA3LCAyMDE2IDI6MDggUE08YnI+DQo8Yj5Ubzo8L2I+IFlvYXYg TmlyICZsdDt5bmlyLmlldGZAZ21haWwuY29tJmd0OzsgSHViZXJ0IEthcmlvICZsdDtoa2FyaW9A cmVkaGF0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW1RMU10gW0ZPUkdFRF0gUmU6IG5vIGZhbGxiYWNrcyBwbGVhc2UgW3dhczog RG93bmdyYWRlIHByb3RlY3Rpb24sIGZhbGxiYWNrcywgYW5kIHNlcnZlciB0aW1lXTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKdW4g NywgMjAxNiBhdCA1OjA2IFBNIFlvYXYgTmlyICZsdDs8YSBocmVmPSJtYWlsdG86eW5pci5pZXRm QGdtYWlsLmNvbSI+eW5pci5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0 OyBPbiA3IEp1biAyMDE2LCBhdCA4OjMzIFBNLCBIdWJlcnQgS2FyaW8gJmx0OzxhIGhyZWY9Im1h aWx0bzpoa2FyaW9AcmVkaGF0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmhrYXJpb0ByZWRoYXQuY29t PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gVHVlc2RheSAwNyBKdW5lIDIw MTYgMTc6MzY6MDEgWW9hdiBOaXIgd3JvdGU6PGJyPg0KJmd0OyZndDsgSeKAmW0gbm90IHN1cmUg dGhpcyBoZWxwcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEnigJl2ZSBuZXZlciBpbnN0 YWxsZWQgYSBzZXJ2ZXIgdGhhdCBpcyB2ZXJzaW9uIGludG9sZXJhbnQuIFRMUyBzdGFja3M8YnI+ DQomZ3Q7Jmd0OyBmcm9tIE9wZW5TU0wsIE1pY3Jvc29mdCw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBh cmUgeW91IHN1cmUgYWJvdXQgdGhhdCBNaWNyb3NvZnQgcGFydD88YnI+DQomZ3Q7PGJyPg0KJmd0 OyB0aGVyZSBpcyBxdWl0ZSBhIGxvbmcgdGhyZWFkIG9uIHRoZSBmaWxlemlsbGEgZm9ydW1zIGFi b3V0IFRMUyB2ZXJzaW9uPGJyPg0KJmd0OyB0b2xlcmFuY2UgaW4gSUlTOjxicj4NCiZndDsgPGEg aHJlZj0iaHR0cHM6Ly9mb3J1bS5maWxlemlsbGEtcHJvamVjdC5vcmcvdmlld3RvcGljLnBocD9m PTImYW1wO3Q9Mjc4OTgiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZm9ydW0uZmlsZXppbGxh LXByb2plY3Qub3JnL3ZpZXd0b3BpYy5waHA/Zj0yJmFtcDt0PTI3ODk4PC9hPjxicj4NCjxicj4N ClRoYXTigJlzIHN1cnByaXNpbmcuPGJyPg0KPGJyPg0KVGhlIGxhc3QgdGltZSBJIHRlc3RlZCB3 aXRoIGFuIElJUyBzZXJ2ZXJzIGl0IHdhcyBXaW5kb3dzIFNlcnZlciAyMDAzIGFuZCAyMDA4LiBU aGV5IGRpZCBub3Qgc3VwcG9ydCBUTFMgMS4yLCBzbyBJIHdhbnRlZCB0byBjaGVjayBpZiB0aGV5 IGNvdWxkIHRvbGVyYXRlIGEgVExTIDEuMiBDbGllbnRIZWxsby4gVGhleSBkaWQuIE9mIGNvdXJz ZSwgdGhleSByZXBsaWVkIHdpdGggVExTIDEuMCwgYnV0IHRoYXQgd2FzIGV4cGVjdGVkLjxicj4N Cjxicj4NCkl04oCZcyBzdHJhbmdlIHRoYXQgdGhpcyBiZWhhdmlvciB3b3VsZCBkZWdyYWRlIGZv ciBtdWNoIG5ld2VyIHZlcnNpb25zIG9mIFdpbmRvd3MgdGhhdCBjYW1lIG91dCBhdCBhIHRpbWUg d2hlcmUgc2V2ZXJhbCBicm93c2VycyB3ZXJlIGFscmVhZHkgb2ZmZXJpbmcgVExTIDEuMi4gSSB3 b25kZXIgaWYgaXTigJlzIGp1c3QgdGhlIEZUUCBvciBhbHNvIElJUy48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgdGhl IGZpcnN0IEkndmUgaGVhcmQgb2YgdGhpcyBhbmQgSSBiZWxpZXZlIG5laXRoZXIgQ2hyb21lIG5v ciBGaXJlZm94IGFjY2VwdCBUTFMgMS4yIGludG9sZXJhbmNlIGFuZCBiZWxvdyBhbnltb3JlLiBU byBteSBrbm93bGVkZ2UsIHRoYXQgaGFzIHN1Y2Nlc3NmdWxseSBiZWVuIGRyaXZlbiBvdXQgb2Yg dGhlIGVjb3N5c3RlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RGF2aWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN3PR03MB1445876F534D9F09882F7B3F8C5D0BN3PR03MB1445namp_-- From nobody Tue Jun 7 14:23:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B845812D52F for ; Tue, 7 Jun 2016 14:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMpRGHiaV4c3 for ; Tue, 7 Jun 2016 14:23:21 -0700 (PDT) Received: from SNT004-OMC3S10.hotmail.com (snt004-omc3s10.hotmail.com [65.55.90.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470DC12D60D for ; Tue, 7 Jun 2016 14:23:21 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com ([65.55.90.137]) by SNT004-OMC3S10.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 7 Jun 2016 14:23:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BqV/EkGOsdCINggRGJFT/ThDKiC6E539qMwGkrAwTSo=; b=KZbimHLAW1rcgLtA80qkNCRtyr/MBw8KxCmhtDhPmrnwvIlulCRSrWhGTI9X2/n6KVxuX02EX4o4hefZMu4HKY3bK86khiJ02U8HL7XtL0Sp/Ybp5D1HQEjNpNOX/ODNiWVteEMrDP/SHMZTouMIFU2DmhDwc3JiXEFWchV+qEqx9sosjbfdvO/hFqPhEV1PrtnwAa5fe9qOMrY0wbgB1dxO+R+hmV5vtCOP1bfXlX8ZMONK9mho0YhLWPt02nE41njF2Ddh3+GtKpU7xtVIogeV8PnLOcjIw1ZNOZCCP1bUYRBgekdGEcI6uYvJB0wJbYp2/5M0cC/4hoTk+PFjrg== Received: from BN3NAM01FT044.eop-nam01.prod.protection.outlook.com (10.152.66.57) by BN3NAM01HT229.eop-nam01.prod.protection.outlook.com (10.152.66.220) with Microsoft SMTP Server (TLS) id 15.1.497.8; Tue, 7 Jun 2016 21:23:19 +0000 Received: from CO1PR07MB283.namprd07.prod.outlook.com (10.152.66.55) by BN3NAM01FT044.mail.protection.outlook.com (10.152.66.243) with Microsoft SMTP Server (TLS) id 15.1.511.7 via Frontend Transport; Tue, 7 Jun 2016 21:23:18 +0000 Received: from CO1PR07MB283.namprd07.prod.outlook.com ([169.254.3.159]) by CO1PR07MB283.namprd07.prod.outlook.com ([169.254.3.159]) with mapi id 15.01.0501.018; Tue, 7 Jun 2016 21:23:18 +0000 From: Yuhong Bao To: Andrei Popov , David Benjamin , Yoav Nir , Hubert Kario Thread-Topic: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] Thread-Index: AQHRwIH0vKbJKDLeak6qbONpPn1qEJ/eDvwAgAAD04CAADGhgIAAO3CAgAAAdACAAAHTAIAAAlpZ Date: Tue, 7 Jun 2016 21:23:18 +0000 Message-ID: References: <19D9A152-3801-44DA-ADF0-345011EDF54D@gmail.com> <4418055.GXTqvqFNm1@pintsize.usersys.redhat.com> <60729080-E56E-41D5-AAB0-FAD46FCE1C00@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=softfail (sender IP is 25.152.66.55) smtp.mailfrom=hotmail.com; microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=fail action=none header.from=hotmail.com; received-spf: SoftFail (protection.outlook.com: domain of transitioning hotmail.com discourages use of 25.152.66.55 as permitted sender) x-tmn: [TyiHHtwkIS9hovG620dzl6HzSeAArETJ] x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:25.152.66.55; IPV:NLI; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3NAM01HT229; H:CO1PR07MB283.namprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 92c9fd6e-971c-422b-8a39-08d38f19f232 x-microsoft-antispam: UriScan:; BCL:1; PCL:0; RULEID:(1601124038)(5061506196)(5061507196)(1603103041)(1601125047); SRVR:BN3NAM01HT229; x-exchange-antispam-report-cfa-test: BCL:1; PCL:0; RULEID:(432015012)(82015046); SRVR:BN3NAM01HT229; BCL:1; PCL:0; RULEID:; SRVR:BN3NAM01HT229; x-forefront-prvs: 09669DB681 Content-Type: multipart/alternative; boundary="_000_CO1PR07MB283907E5F210A94BE818DA6C35D0CO1PR07MB283namprd_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2016 21:23:18.8320 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT229 X-OriginalArrivalTime: 07 Jun 2016 21:23:20.0569 (UTC) FILETIME=[D0AF2690:01D1C102] Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2016 21:23:24 -0000 --_000_CO1PR07MB283907E5F210A94BE818DA6C35D0CO1PR07MB283namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I hope that this fix is in the GDR branch now. TLS 1.2 is important. ________________________________ From: TLS on behalf of Andrei Popov Sent: Tuesday, June 07, 2016 2:14:32 PM To: David Benjamin; Yoav Nir; Hubert Kario Cc: tls@ietf.org Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protect= ion, fallbacks, and server time] Jumping to the end of the thread, it looks like this is an FTP issue that r= epros when TLS 1.2 is negotiated. Not a TLS version intolerance. The conclusion seems to be that https://support.microsoft.com/en-us/kb/2888= 853 resolves the issue, by updating FTP binaries. Cheers, Andrei From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of David Benjamin Sent: Tuesday, June 7, 2016 2:08 PM To: Yoav Nir ; Hubert Kario Cc: tls@ietf.org Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protect= ion, fallbacks, and server time] On Tue, Jun 7, 2016 at 5:06 PM Yoav Nir > wrote: > On 7 Jun 2016, at 8:33 PM, Hubert Kario > wrote: > > On Tuesday 07 June 2016 17:36:01 Yoav Nir wrote: >> I'm not sure this helps. >> >> I've never installed a server that is version intolerant. TLS stacks >> from OpenSSL, Microsoft, > > are you sure about that Microsoft part? > > there is quite a long thread on the filezilla forums about TLS version > tolerance in IIS: > https://forum.filezilla-project.org/viewtopic.php?f=3D2&t=3D27898 That's surprising. The last time I tested with an IIS servers it was Windows Server 2003 and 2= 008. They did not support TLS 1.2, so I wanted to check if they could toler= ate a TLS 1.2 ClientHello. They did. Of course, they replied with TLS 1.0, = but that was expected. It's strange that this behavior would degrade for much newer versions of Wi= ndows that came out at a time where several browsers were already offering = TLS 1.2. I wonder if it's just the FTP or also IIS. This is the first I've heard of this and I believe neither Chrome nor Firef= ox accept TLS 1.2 intolerance and below anymore. To my knowledge, that has = successfully been driven out of the ecosystem. David --_000_CO1PR07MB283907E5F210A94BE818DA6C35D0CO1PR07MB283namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I hope that this fix is in the GDR branch now. TLS 1.2 is important.

From: TLS <tls-bounces@i= etf.org> on behalf of Andrei Popov <Andrei.Popov@microsoft.com> Sent: Tuesday, June 07, 2016 2:14:32 PM
To: David Benjamin; Yoav Nir; Hubert Kario
Cc: tls@ietf.org
Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade = protection, fallbacks, and server time]
 

Jumping to the end of the thread, it = looks like this is an FTP issue that repros when TLS 1.2 is negotiated. Not= a TLS version intolerance.

The conclusion seems to be that https://support.= microsoft.com/en-us/kb/2888853 resolves the issue, by updating FTP bina= ries.

 

Cheers,

 

Andrei

 

From: TLS [mailto:tls-bounces@ietf.o= rg] On Behalf Of David Benjamin
Sent: Tuesday, June 7, 2016 2:08 PM
To: Yoav Nir <ynir.ietf@gmail.com>; Hubert Kario <hkario@re= dhat.com>
Cc: tls@ietf.org
Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade = protection, fallbacks, and server time]

 

On Tue, Jun 7, 2016 at 5:06 PM Yoav Nir <ynir.ietf@gmail.com> wrote:


> On 7 Jun 2016, at 8:33 PM, Hubert Kario <hkario@redhat.com> wrote:
>
> On Tuesday 07 June 2016 17:36:01 Yoav Nir wrote:
>> I’m not sure this helps.
>>
>> I’ve never installed a server that is version intolerant. TL= S stacks
>> from OpenSSL, Microsoft,
>
> are you sure about that Microsoft part?
>
> there is quite a long thread on the filezilla forums about TLS version=
> tolerance in IIS:
> https://forum.filezilla-project.org/viewtopic.php?f=3D2&t=3D27898
That’s surprising.

The last time I tested with an IIS servers it was Windows Server 2003 and 2= 008. They did not support TLS 1.2, so I wanted to check if they could toler= ate a TLS 1.2 ClientHello. They did. Of course, they replied with TLS 1.0, = but that was expected.

It’s strange that this behavior would degrade for much newer versions= of Windows that came out at a time where several browsers were already off= ering TLS 1.2. I wonder if it’s just the FTP or also IIS.<= /p>

 

This is the first I've heard of this and I believe n= either Chrome nor Firefox accept TLS 1.2 intolerance and below anymore. To = my knowledge, that has successfully been driven out of the ecosystem.<= /o:p>

 

David

--_000_CO1PR07MB283907E5F210A94BE818DA6C35D0CO1PR07MB283namprd_-- From nobody Tue Jun 7 14:28:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D34812D873 for ; Tue, 7 Jun 2016 14:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhggIcZNK7rs for ; Tue, 7 Jun 2016 14:28:37 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002: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 7DDB212D86D for ; Tue, 7 Jun 2016 14:28:37 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id x189so182683040ywe.3 for ; Tue, 07 Jun 2016 14:28:37 -0700 (PDT) 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-transfer-encoding:message-id; bh=YuSAdemDGnY2kBsNPTuGFlSogFwKXqV8Gfuwb4IbmXE=; b=jaU4iz4BwS6XQosltDVGj+mCyE3vfUOckn0xDgPJ72AmggZnRnWh4lmEROtB39bB/v iY1JhZiymhIfqy9wVJMlOsuEREG81LxiMH0/sA7lf+K2tPNmXZpKwc+uJDMc0ai0iyWd 0egD/p5yb0ki388UzrBzwERkIyBCYOoFYQqKtJWil/PVb3RCIv5VHxai7giiI+M+RrSm IqTb1XMcyW9AABtb1t/r3cSeZTFB5o1h2i17XzfZklZ2vJENpW9JjGhAcmLr2bKRhmg8 9MwJU8Bo2f9ow330E6q7WS/zt++cKMHtfc6Ujxe9ji6VOYAGmRtqbCQPwRVXzFjShfLX gQVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=YuSAdemDGnY2kBsNPTuGFlSogFwKXqV8Gfuwb4IbmXE=; b=aoYnkxH5A8WHl7g2sYoT0FVtwhLdyZg0tcIWtNSY30gPE1VhyE57ofOAX6AexWNlUH 3u1ErOakZothkDAODx0GDFMz3bTeeeay9Be1cr/0olgimQvhYmaq8+KXGU676MRv/uqH OTqfNv5hyz5FoPekqdNpTySZyKtLKBmRoch9eDxkZRyHQQJ7KC0Mkyg0HHupzR1sjVXI FwM4Vo1g5Brvl+ZmdwLk0u5Bq9aYZh3JqnDti2LyFeEaQRAYPXt2biDensJcUeflWCw5 bjd3J8ax3aT5sSavRpBNIwZn7nSYzFm/2htMMboIIoevVOP0fM11niOtF92T+xWZE5wC T62Q== X-Gm-Message-State: ALyK8tLGrUc5Q4ca+8Tagd0L8G/C0i/w8IoETsQFec6B/eURmNN/qAyPL0Gk2nhQqmoYzw== X-Received: by 10.129.86.5 with SMTP id k5mr989040ywb.141.1465334916720; Tue, 07 Jun 2016 14:28:36 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id d71sm15505834ywb.50.2016.06.07.14.28.35 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 07 Jun 2016 14:28:35 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 7 Jun 2016 17:28:34 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20160606171459.20797.7839.idtracker@ietfa.amsl.com> <3372929.xMFAkkVyhb@pintsize.usersys.redhat.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201606071728.34613.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Fwd: I-D Action: draft-lemon-tls-blocking-alert-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2016 21:28:39 -0000 On Tuesday, June 07, 2016 03:57:32 pm Ted Lemon wrote: > The point of the different result codes is to give the end-user some basis > for figuring out why they didn't get to the site. "Malicious site" is > different than "policy violation." A malicious site is a site that serves > malware, or does phishing, or typosquatting, or something like that. > Policy violation could be "no facebook during business hours." Policies > are typically under user control, so being able to know that you can do > something to address the problem is key. I think the problem that we would want to stress here is that there are far too many places where things that people just don't like get treated as "malicious" and policies are created to block them. The difference between the two is valid, but I have no faith whatsoever that people can really rely on them being properly labeled and communicated. As far as I'm concerned, the determination of explicit designation as malicious is up to the client and any sort of its _own_ content blocking, not anything on the network. As such, I feel like these two alerts can't safely be considered separate. One alert simply for all prohibited connections, without trying to explain human reasoning in one bit of information, would be preferable. Likewise, I don't immediately see why captive portals are sufficiently different from the account attention requested/required cases to warrant separate designation. Upon reading the draft, my first impression is that a set of 3 codes (preferably named more akin to: network_prohibited_connection, network_account_reqested, network_account_required) instead of the current 5 would be more appropriate, and even then, the please/maybe/whatever nature of the second one seems a little odd to me. Just the two "nobody allowed ever" and "you're not allowed (yet)" alerts are the only ones I see particularly convincing justification for. Dave From nobody Tue Jun 7 14:41:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304A112B03F for ; Tue, 7 Jun 2016 14:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAYKmKpIVGeg for ; Tue, 7 Jun 2016 14:41:00 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002: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 51D5412B00D for ; Tue, 7 Jun 2016 14:41:00 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id h19so183069048ywc.0 for ; Tue, 07 Jun 2016 14:41:00 -0700 (PDT) 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-transfer-encoding:message-id; bh=Ys3aEFr6sy9REoxr6mF4kjDFmDrav6fdRrjwtuMdsBI=; b=Td0GMKhSf90Uy1aLq/p6AwN83SHO36pIQgm2gKGAl5VJtNygj7F+5lWbl2103dIpzh chgHPtE5jPQ0MdAJlL0qN8br/1Xb5ShgHfWbBUGsVDLGPRx4rk9u3RiDzn2bsoeRoLTN tLiksaFvJ8XYImzm1F7w/qIh2lUONgRDTg3n0184BpdPbwiTywCMYYmZpTS+yec2NxcH 2wEGqaz+kk6Apkg1svl/uIWRSqQbX2JdMNYsnuj/HDGyso9/jA/8D6RPI+pKjClVW/Zy ZkfENWx40dB/0L0g2gF0P3tKEaBkbAurWaQwGgy+oI6twaQ030DA1on1v7DTtZN0Noae cs9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=Ys3aEFr6sy9REoxr6mF4kjDFmDrav6fdRrjwtuMdsBI=; b=bIVbvSWkwSfokJ2mZeecKAMnpsPzEO53OsfZ9WhdEHs2CGOvq7agNIrLq5e89QYKoz 9I2Lsv5YgN9b0VKGY/Q2dG0zjGuPYjHp5FgBNbBRbWOvo+DKbkOo03JenD9QDliM8kQW Y9oU1QonyROzcUayBFgfmgsnmQYHvVggGv1ZjawLBTse21xSfu29ZD8euQMDCVALYbJt GtDjNpawPYwneg2qFQfZKYKUFOQ2wz3GSzWDR973LC4GYUsV1IchiThL5AqO7AQ/EQfn z6keKxoWM7vp8knjREFmalGOvky75bj5Xvz9TFPcBy8gA7AsydgLCQ+PZQEIlhYyPIoq Wgew== X-Gm-Message-State: ALyK8tKaIH+F4BCm+8MkzocC7wwV6vxqBS9J9+tsKqULCMSLxvj1MixmdaB0dF7ZhpPl6w== X-Received: by 10.13.238.69 with SMTP id x66mr1007482ywe.15.1465335659611; Tue, 07 Jun 2016 14:40:59 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id w192sm15531790ywd.34.2016.06.07.14.40.59 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 07 Jun 2016 14:40:59 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 7 Jun 2016 17:40:57 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <60729080-E56E-41D5-AAB0-FAD46FCE1C00@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201606071740.58077.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2016 21:41:02 -0000 On Tuesday, June 07, 2016 05:08:00 pm David Benjamin wrote: > On Tue, Jun 7, 2016 at 5:06 PM Yoav Nir wrote: > > > On 7 Jun 2016, at 8:33 PM, Hubert Kario wrote: > > > On Tuesday 07 June 2016 17:36:01 Yoav Nir wrote: > > >> I=E2=80=99m not sure this helps. > > >> > > >> I=E2=80=99ve never installed a server that is version intolerant. TL= S stacks > > >> from OpenSSL, Microsoft, > > > > > > are you sure about that Microsoft part? > > > > > > there is quite a long thread on the filezilla forums about TLS version > > > tolerance in IIS: > > > https://forum.filezilla-project.org/viewtopic.php?f=3D2&t=3D27898 > > > > That=E2=80=99s surprising. > > > > The last time I tested with an IIS servers it was Windows Server 2003 a= nd > > 2008. They did not support TLS 1.2, so I wanted to check if they could > > tolerate a TLS 1.2 ClientHello. They did. Of course, they replied with = TLS > > 1.0, but that was expected. > > > > It=E2=80=99s strange that this behavior would degrade for much newer ve= rsions of > > Windows that came out at a time where several browsers were already > > offering TLS 1.2. I wonder if it=E2=80=99s just the FTP or also IIS. >=20 > This is the first I've heard of this and I believe neither Chrome nor > Firefox accept TLS 1.2 intolerance and below anymore. To my knowledge, th= at > has successfully been driven out of the ecosystem. ;) Driven out of the higher traffic mainstream ecosystem, maybe, but there wil= l be a long tail of junk servers that stay around for entirely too long (re= ad: "forever"), in spite of current versions of clients not accepting it an= ymore. My tracking meta-bug in Mozilla's Bugzilla may have finally been clo= sed last month, but that's just tickets filed by people who can actually ge= t a report into the thing. Most people just see such brokenness as the brow= ser's fault and switch to any (older) browser with compatible brokenness, a= nd to any of us they're invisible. The non-trivial population of servers that are TLS 1.0-1.2 version tolerant= but not TLS 1.3+ version tolerant is a far more worrying problem, though. Dave From nobody Wed Jun 8 02:58:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6817012D192 for ; Wed, 8 Jun 2016 02:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.348 X-Spam-Level: X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzXrFY3sGTS5 for ; Wed, 8 Jun 2016 02:58:24 -0700 (PDT) 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 C3BD912D178 for ; Wed, 8 Jun 2016 02:58:24 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5CC93C05B1FB; Wed, 8 Jun 2016 09:58:24 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-122.brq.redhat.com [10.34.0.122]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u589wN4p025955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jun 2016 05:58:24 -0400 From: Hubert Kario To: Andrei Popov Date: Wed, 08 Jun 2016 11:58:22 +0200 Message-ID: <3076488.KRSuv77WAr@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.11-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart28184795.m22O2xIyVR"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 08 Jun 2016 09:58:24 +0000 (UTC) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 08 Jun 2016 09:58:26 -0000 --nextPart28184795.m22O2xIyVR Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 07 June 2016 21:14:32 Andrei Popov wrote: > Jumping to the end of the thread, it looks like this is an FTP issue > that repros when TLS 1.2 is negotiated. Not a TLS version > intolerance. > The conclusion seems to be that > https://support.microsoft.com/en-us/kb/2888853 resolves the issue, by= > updating FTP binaries.=20 > Cheers, yes that thing should be fixed now that being said, I've seen reports that IIS 7.5 does support TLSv1.2=20= while at the same time being intolerant to TLS 1.3 Client Hello. Unfortunately I don't have access to a server that I'm certain is=20 running IIS 7.5 that I could test this hypothesis with. To continue my reply to Yoav, so just because we sometimes not see=20 different intolerancies, doesn't mean they are not there. TLS library=20= programmers do actively shape their Client Hello's to trigger as little= =20 issues as possible. =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 --nextPart28184795.m22O2xIyVR 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 iQIcBAABCgAGBQJXV+w+AAoJEJKo0bgB0vX1qAQP/iGyutNnd95xN3gwMCQnKmnF Uk0euYVvcmgrKKN8oO62ausbg1CcShMOieHwV9f7rmZwLSudKvKRwNCGsLw9WLvG aiyDWwm2bisUE1CxEJ8dVCX0mT/yONUA24rlr+QU7PDYBQOj9guRwUQ1FEhKzfMi jRMUgPrqibSA8x2QWo6vI6p1DvhfSGIQXhWYDg8gzi577F9Q5NLMZkV2KhQo9ODw V7vyO0m7LqsBvl5ERSVwrZWDBP70HdrZYsIlTOrUnc4HfXeYX5LEij9n/CRfDFp8 j0mPJ4gn+jJeiV/P4aXBlLaULMgeJYF2GLSJlnZBs0YaIl3S+zB8rrcZxr35iW0Q lyLPCB6E4Lk7g0J+Q4ZYGaAzth3AMAeOemUd+dkT4XSBhGS3LRZszc8HIAYflZze hf5AjwwCjA0xLnyohrEc92p1IhmwUXHZOKrTwc2q+I4DQgHp2+ETht4kAUIKyQli ULpiQwEW0Is237GwNLYsfkRLBYYRCIPG0eWTPj4dORWNRb3485fdYJ1DxfZ1ufqZ wfKorU1LCV2DHZsGlix2vlqwVsN56Kk5hoYIDRRyhYRHuf/lIv3vnjXF7jj1zgD4 K/kt66VvaF2T1hudvMAtSEYLoweBukIXF3+7y4Ef0ya+61LqFSBPORx6PSUqXM4/ /lWtfD3Dm42JSz/I6SCy =6QJc -----END PGP SIGNATURE----- --nextPart28184795.m22O2xIyVR-- From nobody Wed Jun 8 11:18:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875F912B01A for ; Wed, 8 Jun 2016 11:18:19 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esh5M4VzvyIk for ; Wed, 8 Jun 2016 11:18:18 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42FA412B004 for ; Wed, 8 Jun 2016 11:18:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3A40B3002BF for ; Wed, 8 Jun 2016 14:18:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 63SM0U2jvttV for ; Wed, 8 Jun 2016 14:18:15 -0400 (EDT) Received: from [5.5.33.196] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id E36EB30025D; Wed, 8 Jun 2016 14:18:14 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C9CA49@uxcn10-5.UoA.auckland.ac.nz> Date: Wed, 8 Jun 2016 14:18:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C73F4C9CA49@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF TLS Subject: Re: [TLS] Adoption of TLS-LTS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 08 Jun 2016 18:18:19 -0000 Peter: I skimmed this draft. It is not just a profile of TLS 1.2. It makes = TLS 1.2 protocol changes. I do not think the TLS WG should take on any document that makes changes = to the TLS 1.2 protocol. Russ On Jun 6, 2016, at 9:05 AM, Peter Gutmann = wrote: > TLS-LTS, https://tools.ietf.org/html/draft-gutmann-tls-lts-03, has = more or > less stabilised, incorporating all the feedback I've had for it = (there's only > one open question still remaining), so I'd like to request that it now = be > adopted as a WG item. >=20 > I'd also like to request an early/temporary assignment for an = extension ID, to > provide something a bit more usable than the much-overloaded 0x42 = that's > currently being used. >=20 > Peter. From nobody Wed Jun 8 12:29:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9ED12D5A2 for ; Wed, 8 Jun 2016 12:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGiVD7uWAg3g for ; Wed, 8 Jun 2016 12:29:13 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF73812D196 for ; Wed, 8 Jun 2016 12:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1465414152; x=1496950152; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=X2K/8mtXp6m8+SXThndf21DmmKuaKtEX8nT1SG3AJ6I=; b=Y3YyPnHK2VIyq/3bwFQRa0XC/ZJynSF9csOK874en1eePdZeZ4azCcj3 KAtILoVTqNWf1DFts8oE9nj+JXsfNre/00FLMyQVZsD3GavkA5SFfetCS 19QXuSM84OTd01qzfZ7sfJhg4CqF5279SK2+PkNmn9K6B7w3JKpI+akbL iVTeoVp6C8+2a9N+rA6KiH7PRpbHx7sE0FNVto7hR5DKb3kVJGlUd1Rdz 4jKgWg7Sdhjwek+VhRc3K1qEMrNgtP1cfek7iaOEgtG8soMZlz8jhCEh5 urV9CuIMah3jvsr4Oh3qQcoSxc/Vrlb95s/PcO4KfPcEtjsyzAnSFPtc2 g==; X-IronPort-AV: E=Sophos;i="5.26,440,1459771200"; d="scan'208";a="90372538" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Jun 2016 07:29:07 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Thu, 9 Jun 2016 07:29:08 +1200 From: Peter Gutmann To: Russ Housley Thread-Topic: [TLS] Adoption of TLS-LTS Thread-Index: AdG/9CVqy8MYXur6TqWx/88FbT3L7gBWWRwAABuaKxI= Date: Wed, 8 Jun 2016 19:29:07 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C9E044@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C9CA49@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: [10.6.3.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF TLS Subject: Re: [TLS] Adoption of TLS-LTS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 08 Jun 2016 19:29:15 -0000 Russ Housley writes:=0A= =0A= >I do not think the TLS WG should take on any document that makes changes t= o=0A= >the TLS 1.2 protocol.=0A= =0A= So how is that different from any number of other TLS standards-track RFCs,= =0A= say, RFC 7627 (one of the ones referenced in the draft), which was adopted = as=0A= a WG document and standards-track RFC? The tiny changes in this draft (add= ing=0A= one field to the ServerDHParams, using the full MAC for finished, and hashi= ng=0A= the full hello instead of just one field in it) are pretty trivial in=0A= comparison to the aforementioned RFC 7627, or any number of other ones.=0A= =0A= Peter.=0A= From nobody Wed Jun 8 12:47:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB8612D53A for ; Wed, 8 Jun 2016 12:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCZSGrVRenps for ; Wed, 8 Jun 2016 12:47:54 -0700 (PDT) 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 E209A12B053 for ; Wed, 8 Jun 2016 12:47:53 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id m124so31378815wme.1 for ; Wed, 08 Jun 2016 12:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lQ2Cd5B5F85kfOutMaEraDqWuchr1T5DI5j8MTI2p9g=; b=o2XK749iLTXxiGSoTz0DGOcg1wZCIKvk14Pv1U2iDzbv9wkSRHvBsYIhFF+V6h6nCv vdWtIp6Sais7+FfS9/wrqICQbL5MyhAGiFQy2q9Wx2tzbITFpr0RVeuQoSLty5HWvjrp a8gAFLpz8PeZtFYnXXvpabeEhA0Um9+HXuSE3GV/7PJAGPO1Z3RVSYEC+RdPY4ROVW6D i5UFmlk532bO4lRRpxuWcdMRpxHE4IzJMqhAnsmqiVY7NYlrJrotUVQ8YR9CFFhtF24k nQMcSJeAgk7yD8m62H4LPYFQdl+JaUMfS+yi/w92QY8FJ0DR3oMEw9QbS88yx+SFrz/R AXrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lQ2Cd5B5F85kfOutMaEraDqWuchr1T5DI5j8MTI2p9g=; b=OtsebOXIGZ7YUKRA2DIxUW+lMM3V44edwcikRXT3P32pxuuuQqBO9yqEGELIeqi592 64woHumFSxWJ8yQQf/75p3Z9lF5/OXT5aE1De9htf/VsNsb8y+AbLi55F775MO/b+cUE 4afBmN7twDjRfrFvXWTVe7Di1ZNUHReAopcYB50BxHtMqFy0PSfaimIm3IJF58b0ufQT aIPXdeYh0UG1ODzHbdQBRKwvDpPF/YUbA9CnhJivB5tqOVexoYFdSQRVXtutUp42www5 E4A6kY9XkjU7qY04PPIM5lhWLlrvlM9U+uXJjGYY3QjwN49FZ7AsVvF7h+MlP3R1BV7G MnxA== X-Gm-Message-State: ALyK8tI0XIx4iK880JFkgXkZXkpcIQzCBLsVZ/jlNps1F6ZoUg0vfjNjCUtrXCjtEjQTqw== X-Received: by 10.28.144.7 with SMTP id s7mr9727954wmd.103.1465415272452; Wed, 08 Jun 2016 12:47:52 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id u70sm16702685wmd.4.2016.06.08.12.47.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Jun 2016 12:47:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C9E044@uxcn10-5.UoA.auckland.ac.nz> Date: Wed, 8 Jun 2016 22:47:50 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <43EA3401-F5E5-4111-AECD-847E7ABEFB83@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4C9CA49@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C9E044@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF TLS Subject: Re: [TLS] Adoption of TLS-LTS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 08 Jun 2016 19:47:56 -0000 > On 8 Jun 2016, at 10:29 PM, Peter Gutmann = wrote: >=20 > Russ Housley writes: >=20 >> I do not think the TLS WG should take on any document that makes = changes to >> the TLS 1.2 protocol. >=20 > So how is that different from any number of other TLS standards-track = RFCs, Mostly timing. The TLS working group is now working on TLS 1.3, so 1.2 = should be considered stable by now.=20 We=E2=80=99re not actively developing older versions. Yoav From nobody Wed Jun 8 12:57:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808BE12D739 for ; Wed, 8 Jun 2016 12:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIYYTRTddjki for ; Wed, 8 Jun 2016 12:57:15 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D20D12D619 for ; Wed, 8 Jun 2016 12:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1465415835; x=1496951835; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=l06Ym0TVOGR3WuGmkOBA/7Tm1JPNNrl6yEONUWxpcxU=; b=nR3yGkeHTZSPQf/oL79hx04GzL+gBGWQeJoUkSHqi29QWAwTc8PRaxx+ wRCF+kUKgVfoXh5X8aEhvWuQh4ptdj6wctdCT09Jj3jjpKEkwstMvtfi4 BfN9GeDevKkJ0uQ1wSjFJfLWBaOnhf81Z7tHtcKW0183G/abqf1uiuYwz 9LGpR05MzISNb1ChVqk/HamGGu+rA3CqnIvCgfq6X3mnFFcjJ7/E6MceF ySgODJOQNfu3nBDl1JE+Q0sztxJLl8bDDGf32UMp773Mciuyia8OCio8y FCMWIyjas1rdlttloZ2GgIEB3gwl0PhTjHkQBYoUFIYQ2l9mWrBA1Bvub Q==; X-IronPort-AV: E=Sophos;i="5.26,440,1459771200"; d="scan'208";a="90374736" 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; 09 Jun 2016 07:57:13 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Thu, 9 Jun 2016 07:57:13 +1200 From: Peter Gutmann To: Yoav Nir Thread-Topic: [TLS] Adoption of TLS-LTS Thread-Index: AdG/9CVqy8MYXur6TqWx/88FbT3L7gBWWRwAABuaKxL//zw3AIAAy6WB Date: Wed, 8 Jun 2016 19:57:12 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C9E095@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C9CA49@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C9E044@uxcn10-5.UoA.auckland.ac.nz>, <43EA3401-F5E5-4111-AECD-847E7ABEFB83@gmail.com> In-Reply-To: <43EA3401-F5E5-4111-AECD-847E7ABEFB83@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: [10.6.3.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF TLS Subject: Re: [TLS] Adoption of TLS-LTS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 08 Jun 2016 19:57:16 -0000 Yoav Nir writes:=0A= =0A= >Mostly timing. The TLS working group is now working on TLS 1.3, so 1.2 sho= uld=0A= >be considered stable by now.=0A= =0A= As the draft says, this is intended for long-term support (on the order of = a=0A= decade or more) of existing implementations, not an entirely new, unproven= =0A= protocol.=0A= =0A= Didn't we already have this debate a few months ago?=0A= =0A= Peter.=0A= From nobody Wed Jun 8 13:07:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707A712D53A for ; Wed, 8 Jun 2016 13:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: 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_-Bq0SLrVk0 for ; Wed, 8 Jun 2016 13:07:44 -0700 (PDT) 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 D4F0B12D7CD for ; Wed, 8 Jun 2016 13:07:43 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id k204so32081433wmk.0 for ; Wed, 08 Jun 2016 13:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WbKuV5AgnQr1ktn/muhUjGnbj92NXa3oSDYIiPMspiU=; b=Id64fRdE8APRrzJmCI6ea6FpX8WuKIbKiVc4vVtmu+fa3Dpaajn3xxBzqJaU/G5qo/ UW+Ic2fJResUUp+5w5P392C4FS/q+uUYU5o+kKJdC+dhSF0eibjNxwe8Oy4JX0G4m3w4 sCl5Y956Q74i7UwMce8s/DTa/tiZqNBxOr1tg5sC3dNxTZSw/n/Z9GP1KwXs52Ox6zVH NnHFX2OhPbirFuh/AbdcUPkxNzowcDgtvAbkIwQbZGAPp31q0n2km+rxvPwmyXbu5+QG RLS7S/lcGcyd+EW2dHXQJAzvnBCo4nfp2TAft5GLBKOuTo4D8Z/DF6wq5qagSgA8q+QL TEuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WbKuV5AgnQr1ktn/muhUjGnbj92NXa3oSDYIiPMspiU=; b=ZghhlLZqdpTkt7WD6ZBI32B1uKueLcx7aELawjBQ3S6d3ExogdU8w9R4WsATx2zBje 06ou3vHdKlbgqbmgX/LeN2GjJVH7H48bAB0vXuYtS7g59uxoID6kHJijzOKSTdh80Ajw s0Um8X4eO52zdDb7USBHnNbLVmIicGKDUbS+5oKsRrQXUynBlDN7vrUXxqMdVXlOOMQS 5X/H9SVKtXxwfddFYjqNIazn2fM5KJAGY6PjMrQYGaRWmnTXoWGRU+X0dtce6P7+wWUZ hvxomE4XvY8kdM6zIraiJlQHW185AVsrA3TQ/CxiSCDCaC+dJ5qErZmLAK6eSxkKVIH7 v3hA== X-Gm-Message-State: ALyK8tLkCFo/pvvm49a1+EL6mNi3NejiWl3F/bt6KaOeH7RbrSmMHRMxsulIs51tPQRYZg== X-Received: by 10.194.139.104 with SMTP id qx8mr5978803wjb.14.1465416462380; Wed, 08 Jun 2016 13:07:42 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id r76sm3843640wme.14.2016.06.08.13.07.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Jun 2016 13:07:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C9E095@uxcn10-5.UoA.auckland.ac.nz> Date: Wed, 8 Jun 2016 23:07:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <682AA49A-5A01-470B-B2C5-186F6F4C8ADD@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4C9CA49@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C9E044@uxcn10-5.UoA.auckland.ac.nz> <43EA3401-F5E5-4111-AECD-847E7ABEFB83@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C9E095@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF TLS Subject: Re: [TLS] Adoption of TLS-LTS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 08 Jun 2016 20:07:46 -0000 > On 8 Jun 2016, at 10:57 PM, Peter Gutmann = wrote: >=20 > Yoav Nir writes: >=20 >> Mostly timing. The TLS working group is now working on TLS 1.3, so = 1.2 should >> be considered stable by now. >=20 > As the draft says, this is intended for long-term support (on the = order of a > decade or more) of existing implementations, not an entirely new, = unproven > protocol. >=20 > Didn't we already have this debate a few months ago? Sure. But then it was your individual draft, so you got to call how the = debate turned out. Now you=E2=80=99re seeking WG adoption. Yoav From nobody Wed Jun 8 22:48:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD87D12B046 for ; Wed, 8 Jun 2016 22:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zq1HlgKU9OcN for ; Wed, 8 Jun 2016 22:48:19 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D892612B043 for ; Wed, 8 Jun 2016 22:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1465451299; x=1496987299; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+b5JfaL4I51pO4IqCs1Rt7co2/ugH/RQCvWch9AdyPs=; b=A433sGbXKo62D+aS9etzQPu+5DQsjg2qZZnhMquFPH9XIoLWX7f84PF+ BB4KvrhHoTGgx9htULvsdBiTUACVeXWVq0H1cEfJ7I5iVJrq+bzQNGkkb W1lY/ZoNTAVJ2UmfOXJHFSbRw70igUGoJxGaoud4ZgSBhF+txA1t7Pfbj 0Ub1Xi4ZRyUWgdgQj8kly/Dx5/W0B7K4TvfFV31VwsJ3oRjsxvAeG6RMK rM6GNp9qTEPqGDPNguoIbmVdbnAwiqfrYUWp8o64ThmdUrF7633cKQeEU 4p4cMZr4lAdNtlEu1PDEGyUyCfn/UF5948BQX3PnfPw8kDjDao7qIu8H4 g==; X-IronPort-AV: E=Sophos;i="5.26,443,1459771200"; d="scan'208";a="90502905" 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; 09 Jun 2016 17:48:16 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Thu, 9 Jun 2016 17:48:15 +1200 From: Peter Gutmann To: Hubert Kario , Kyle Rose Thread-Topic: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] Thread-Index: AQHRwMgFSc+0J48oU0SuzFcIH2kf65/dSI8AgANVHXQ= Date: Thu, 9 Jun 2016 05:48:15 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C9E452@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C9D3F0@uxcn10-5.UoA.auckland.ac.nz> , <2698023.3YM6Cv9mer@pintsize.usersys.redhat.com> In-Reply-To: <2698023.3YM6Cv9mer@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: [10.6.3.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 09 Jun 2016 05:48:24 -0000 Hubert Kario writes:=0A= =0A= >The first one is:=0A= >https://github.com/tomato42/tlsfuzzer=0A= >and aims to be a comprehensive test suite=0A= =0A= Very nice, just setting it up now. One minor request, it'd be useful to ha= ve=0A= a run-evening wrapper script that steps through each test reporting what's= =0A= happening, so first to a standard connec to make sure all is OK, then run t= he=0A= various tests. I'll hack toether a shell script in a minute, but having an= =0A= official way of doing it would be nice.=0A= =0A= Peter.= From nobody Thu Jun 9 02:44:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1329B12D0AC for ; Thu, 9 Jun 2016 02:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.348 X-Spam-Level: X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v21_GML9HhcO for ; Thu, 9 Jun 2016 02:44:05 -0700 (PDT) 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 8562312D0A0 for ; Thu, 9 Jun 2016 02:44:05 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D4CDFC04D294; Thu, 9 Jun 2016 09:44:04 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u599i30d001136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jun 2016 05:44:04 -0400 From: Hubert Kario To: Peter Gutmann Date: Thu, 09 Jun 2016 11:43:57 +0200 Message-ID: <2728571.M7U9SoToVs@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.11-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C9E452@uxcn10-5.UoA.auckland.ac.nz> References: <2698023.3YM6Cv9mer@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C9E452@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1995779.HP4dzx3PnM"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 09 Jun 2016 09:44:05 +0000 (UTC) Archived-At: Cc: "" Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 09 Jun 2016 09:44:07 -0000 --nextPart1995779.HP4dzx3PnM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 09 June 2016 05:48:15 Peter Gutmann wrote: > Hubert Kario writes: > >The first one is: > >https://github.com/tomato42/tlsfuzzer > >and aims to be a comprehensive test suite >=20 > Very nice, just setting it up now. One minor request, it'd be useful= > to have a run-evening wrapper script that steps through each test > reporting what's happening, so first to a standard connec to make > sure all is OK, then run the various tests. I'll hack toether a > shell script in a minute, but having an official way of doing it > would be nice. run _everything_ is not really possible as some tests actually require=20= mutually exclusive server settings - e.g. some require the server not t= o=20 ask for client certificate while others do later in tests I've started adding a "sanity check" test case (see=20 "test-certificate-verify.py"), but I didn't yet have time to do that fo= r=20 all all in all, I won't hide that they are very rough, but this is not the=20= intended user interface; the scripts are just proof-of-concept for the=20= test engine, there will be two levels above it before the real user=20 interface will come into play finally, while I do look forward to any contributions (just ideas for=20= tests would be huge help!) I do want the tool to be as platform=20 independent as possible (require just Python runtime, be it 2.6, 3.5 or= =20 anything in-between), so if you do plan to write the script, may I ask=20= you to do that in python too? =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 --nextPart1995779.HP4dzx3PnM 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 iQIcBAABCgAGBQJXWTpdAAoJEJKo0bgB0vX17RIP/jYg4q8m9I81xRv9KwZWr/bl MGvxTfmYhMk7JaNPtEkZVf1NvtZGJmaQt0KhtPgabBnulQhz0nFGq179LR4tsPM3 sDk4av0hy4Mk9MjlPo/XtUvWVQD036UZwUQxFb2CY5gUXkTTyA83RjZent9CGxx1 WW6/ytqkIA+HyScguW0ck3gJkb83tCkPvFShf2v0f+TOJqqU5Dp5hVhf+WEko0TZ PeT6VrSJjCM856lCQJW7YK0VFzLpMeJmbRpDka+Gj/WggmkScc8HiFpU5mhBdRyV zztWa+OJnkPF14j9RWhWDrFvPM6CH5cviZ2BEFcaebTD+BQLobWBxbUZIgImxL1b bKzLeViBGRkXjEuy9xUAtfU90gTBkL/zhFIkbPJ7/ffPm32uw0Zy9ri/oHdRTtyV +U7IgKR4bOg5Cs05pqKKNpCjXcl7f1MQPKLbKpG/1Yx7+7x38kXe+aNVrazaIn7m 4D4ctCGYg0gCSnVf+meyOdCofIe/3Cd4+TFTAaL9CK/K2pBwLrE5EK4kH/1duIZY 03XxQH3YcAgbhCxkujY+ykIBgobGkNh6hg2+nnbtsPUk08HU8d9CuQaC8wsuhbVd HkmM8MHNna/uqwUU2P9rTar/453Bkp+gVoQvHW/bJ5Cx0JY8feHVjM8L9GfFLneM 62WzllNtAIEFP91am6tC =smEK -----END PGP SIGNATURE----- --nextPart1995779.HP4dzx3PnM-- From nobody Thu Jun 9 02:55:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF5712D0A0 for ; Thu, 9 Jun 2016 02:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.348 X-Spam-Level: X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imng64MmCxRt for ; Thu, 9 Jun 2016 02:55:42 -0700 (PDT) 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 7EADA12D0F0 for ; Thu, 9 Jun 2016 02:55:42 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CFFB5C00B8E4; Thu, 9 Jun 2016 09:55:41 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u599tdC2021184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jun 2016 05:55:41 -0400 From: Hubert Kario To: tls@ietf.org Date: Thu, 09 Jun 2016 11:55:39 +0200 Message-ID: <22902566.AuEvmjhU12@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.11-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C9E044@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C9CA49@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C9E044@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5314317.AuqaekqFZz"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 09 Jun 2016 09:55:42 +0000 (UTC) Archived-At: Subject: Re: [TLS] Adoption of TLS-LTS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 09 Jun 2016 09:55:44 -0000 --nextPart5314317.AuqaekqFZz Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 08 June 2016 19:29:07 Peter Gutmann wrote: > Russ Housley writes: > >I do not think the TLS WG should take on any document that makes > >changes to the TLS 1.2 protocol. >=20 > So how is that different from any number of other TLS standards-track= > RFCs, say, RFC 7627 (one of the ones referenced in the draft), which > was adopted as a WG document and standards-track RFC? The tiny > changes in this draft (adding one field to the ServerDHParams, using > the full MAC for finished, and hashing the full hello instead of just= > one field in it) are pretty trivial in comparison to the > aforementioned RFC 7627, or any number of other ones. to be pedantic, the RFC describes itself "a profile" while in reality i= t=20 modifies the protocol in a way that will make it incompatible with=20 "vanilla" TLS 1.2 implementations (yes, I know it's negotiated using extension so it doesn't make it=20 actually incompatible, just noting that the behavior with and without=20= extension is significantly changed - it's not a strict subset of=20 TLSv1.2) =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 --nextPart5314317.AuqaekqFZz 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 iQIcBAABCgAGBQJXWT0bAAoJEJKo0bgB0vX1i1gQAJr7gaWteYSxmPa7ZXKVIAsu 3ux3j6kSO0wRb3t9pWGCfnhXWyURz/N+AfuakEYPNjR2hTKfAwhJWAuGO/VJJwXK kv+evAHKg1vK8vYsQD6disrT9cj3Irzo//RfnedROSHH5Yzzydln7J3DA9odrmWn 1Q6mNlsBzIAEJbOtg132X1qulwMsF7QJk7Z7FT0jqyRSP1/lF3vpOg49MC311YWO 2Zp7NNJOPGGDY1OMITa1vfPGO4L3I6dpWqLhRvJRxozsxPW8/mBkYxAaRZ8aFDmD +Z5liVhZl63cKOL/eLwCgycQ1Opk30SAFVHRjfO7j9dHNet1aE3PlApTo4QPYLfj EWU7cAnmfSLRp7UUf1P+qIc6ZzKT3fXKj5ReNognSkX9d8RcKeKcbpjYMaGR5VhR xamvkEpFo63chcyvTMXlGSRLwhjRKxAvqKpWei9tPXmcHpcrQD+LdiV8884g+RQf r3/TuIsYhxa7bxc/GpuYJe3mCGE8BMzl3jNpycwbxb56mmLCq9vU3lrkRus0/nHD B4WgdMtlbStrtT4Y7r6f2LtaEIbKJRlZ0aTM31BjBEMBf0BObsVupj53KAYdvrDd PDexE0UjegJT6y55MRAFoM8NI/PeNswZh+CddBP5ELoO0TYhTZOY7q/ypbDPmwQs WIeih6hZIeXQRrr98Q/o =6mSx -----END PGP SIGNATURE----- --nextPart5314317.AuqaekqFZz-- From nobody Thu Jun 9 14:56:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA09012DA14 for ; Thu, 9 Jun 2016 14:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lweHtuvmS9Vc for ; Thu, 9 Jun 2016 14:56:43 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3712412D9EC for ; Thu, 9 Jun 2016 14:56:42 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id EBA06F98B; Thu, 9 Jun 2016 17:56:41 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 235752022D; Thu, 9 Jun 2016 17:56:41 -0400 (EDT) From: Daniel Kahn Gillmor To: Joseph Salowey , "tls\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.22+47~g4441900 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 09 Jun 2016 17:56:37 -0400 Message-ID: <87d1nqc9gq.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] Closing on keys used for handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 09 Jun 2016 21:56:45 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri 2016-06-03 17:54:53 -0400, Joseph Salowey wrote: > Trial decryption has serious implementation problems > - > Double-encrypting handshake messages in both the handshake key and the > application key does not actually provide the required key separation > - > Separately encrypting the content type is inefficient in a number of > ways, especially for DTLS (and would need separate security analysis).= This > is probably the most viable of the =E2=80=9Ctry to get both=E2=80=9D d= esigns. I'm saddened by this analysis :( I understand that trial decryption precludes inplace decryption, and i can see why that makes it a non-starter for some implementations. I confess i was hoping that double-encrypting would provide some measure of useful key separation for cryptanalysis. I don't think i understand Ilari's explanation in this thread, though, so i'd appreciate any other attempts to clarify. > This leaves us with two primary alternatives: > > 1. Use the same key (as in the current draft-13) > 2. Restore a public content type and different keys Between these two options, I strongly prefer option 1. > PUBLIC CONTENT TYPES > > Clearly, having a public content type and separate keys for handshake and > application data provides full key separation, at the cost of revealing > whether a given record is handshake or application data (and potentially > alerts). The major question that the group had was whether it was actually > possible to conceal this information effectively, even with encrypted > content types, since hiding the handshake messages in the application > traffic requires detailed knowledge about the application traffic pattern > (e.g., packet lengths, timing, response patterns, etc.). It=E2=80=99s cle= ar some > analysis of this is needed. We know that traffic analysis is difficult, and may in some cases be impossible. This is an area in need of active research. However, deciding to make it *always* impossible to protect because we don't know how to protect it absolutely is "security nihilism", and i hoped we were moving beyond that mindset as a community. If we don't have a mechanism to hide this metadata, then we certainly won't develop any useful practice around actually making it indistinguishable. Protecting users is a multidimensional problem. We should provide a mechanism to make this information indistinguishable in the axis we know how to handle (encrypting the material itself) so that there is a reason for people to work on the axes we don't yet know how to handle (protecting against traffic analysis). --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXWeYVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKJ/wP/0QArG1axGNt4KeNzbDKoRvW gSnUZZidIIVh3nV6OQEgn4Fj9R+5PfHwN48b24J/6nBe1ilBSAzSXgMVK3Cq73uZ V0kfM8RhUiZDamOlJJi85WOXuLSCJZh+PoqyDKXeRyWNApnru43ukznEmYMLKVS4 so52jLtdAJyMLboM66VDgjBIfdDaocN2m4MKINZcVImx8rAzqVVOdzt+Y5UwAoGY LcgeSlApkG3HHXLcBDzg4A+LwBcHBRw1PJTo6pRwClgtE5PFo2dK0n1M5mPX40Ub RgVw0qvbIagirDazadTWBdPfsvK2UWI3adENk9I+9BACTaIqNmJlKPF9S0XKCH4m +ElOy7kpFXH9vULoOyUzVPOYMP70GrVYJEiqe7/0cju1Ty6yNTqb2BPs44VX05kV xvmhz2YCVBc/5fKJx8gHpiq+KupAVk+oRR2vPaxRrhvwpZ3xN3VxIcjlvJufF4Mg 09Qlv+6TehOYEGxo9vqbLKP1cM8IZHDGaIvdglmRH3Tv7GvP6WCFotvZlrDW7Ogq Wzm9A/7Xy4HGV0Q1risdqLb6OgbBfDfSuDPXKmfY7a8Llyu0GWHiSXEmzWKVT9s5 K6lwF9FDwa7y54iRuVcEdzLNOCOotiU9aWptzlwpQp9XTNBqF2oqBL3EqGhF2hHR QdA88S8xLu9HctEwIxjl =N2bS -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 10 02:31:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA1912D572 for ; Fri, 10 Jun 2016 02:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.648 X-Spam-Level: X-Spam-Status: No, score=-5.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10UAaPNJTQpS for ; Fri, 10 Jun 2016 02:31:08 -0700 (PDT) Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) (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 E987412D158 for ; Fri, 10 Jun 2016 02:31:07 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5A9V6dD008245; Fri, 10 Jun 2016 05:31:06 -0400 Date: Fri, 10 Jun 2016 05:31:06 -0400 (EDT) From: Nikos Mavrogiannopoulos To: Yoav Nir Message-ID: <2144997004.41497030.1465551066584.JavaMail.zimbra@redhat.com> In-Reply-To: <60729080-E56E-41D5-AAB0-FAD46FCE1C00@gmail.com> References: <19D9A152-3801-44DA-ADF0-345011EDF54D@gmail.com> <4418055.GXTqvqFNm1@pintsize.usersys.redhat.com> <60729080-E56E-41D5-AAB0-FAD46FCE1C00@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.10.61.108] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF45 (Linux)/8.0.6_GA_5922) Thread-Topic: no fallbacks please [was: Downgrade protection, fallbacks, and server time] Thread-Index: 2qOLttO/wbXnbVe/jaLa9jjhwIVqnw== Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 10 Jun 2016 09:31:09 -0000 I'm actually surprised you mention the microsoft servers as being=20 version negotiation tolerant. They were the most prominent examples of terminating the handshake if TLS 1.2 was offered to them (that=20 was much time before TLS 1.2 was implemented in browsers). regards, Nikos ----- Original Message ----- > On 7 Jun 2016, at 8:33 PM, Hubert Kario wrote: >=20 > On Tuesday 07 June 2016 17:36:01 Yoav Nir wrote: >> I=E2=80=99m not sure this helps. >>=20 >> I=E2=80=99ve never installed a server that is version intolerant. TLS st= acks >> from OpenSSL, Microsoft, >=20 > are you sure about that Microsoft part? >=20 > there is quite a long thread on the filezilla forums about TLS version > tolerance in IIS: > https://forum.filezilla-project.org/viewtopic.php?f=3D2&t=3D27898 That=E2=80=99s surprising. The last time I tested with an IIS servers it was Windows Server 2003 and 2= 008. They did not support TLS 1.2, so I wanted to check if they could toler= ate a TLS 1.2 ClientHello. They did. Of course, they replied with TLS 1.0, = but that was expected. It=E2=80=99s strange that this behavior would degrade for much newer versio= ns of Windows that came out at a time where several browsers were already o= ffering TLS 1.2. I wonder if it=E2=80=99s just the FTP or also IIS. Yoav _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Fri Jun 10 13:43:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DC812D74E for ; Fri, 10 Jun 2016 13:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbD6cDq3B16q for ; Fri, 10 Jun 2016 13:43:10 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229DF12D1B7 for ; Fri, 10 Jun 2016 13:43:08 -0700 (PDT) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d42 with ME id 58j61t00P17Lgi4038j7iz; Fri, 10 Jun 2016 22:43:07 +0200 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWVAd2FuYWRvby5mcg== X-ME-Date: Fri, 10 Jun 2016 22:43:07 +0200 X-ME-IP: 92.170.5.52 To: "tls@ietf.org" , uta@ietf.org From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: Date: Fri, 10 Jun 2016 22:43:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [TLS] Compression along with TLS in NNTP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 10 Jun 2016 20:43:12 -0000 Hi all, Last year, in September 2015, we spoke about the removal of TLS-level compression in TLS 1.2. NNTP was relying on this feature provided by previous TLS versions to compress data. We agreed that the right move was to standardize a new NNTP command. It is what we finally did with the COMPRESS extension. Interoperability is proven: two news servers (INN, Cyrus NNTP) and a news client (flnews) have already implemented it. It also works fine with Python nntplib+zlib libraries. Here is the latest version of the draft: https://tools.ietf.org/html/draft-murchison-nntp-compress-03 If you have any comments, please don't hesitate to tell. Especially, I have a question: o How are TLS (and SASL) specific exchanges supposed to be handled? Should it be mentioned in the RFC that they are outside the scope of NNTP compression? (I speak of stuff like TLS handshakes, renegotiations, etc. that can occur after the use of COMPRESS. OpenSSL may use SSL_read/SSL_write on its own, mayn't it? And it does not know that it should compress data...) Here is an extract of the paragraphs dealing with TLS in the draft, so that you can easily see what to comment (wording improvement, missing stuff...). The point of COMPRESS as an NNTP extension is to behave as a transport layer, similar to STARTTLS [RFC4642]. Compression can therefore benefit to all NNTP commands sent or received after the use of COMPRESS. [...] 1.1. About TLS-level Compression Though data compression is made possible via the use of TLS with NNTP [RFC4642], the best current practice is to disable TLS-level compression as explained in Section 3.3 of [RFC7525]. The COMPRESS command will permit to keep the compression facility in NNTP and control when it is available during a connection. Compared to TLS-level compression [RFC3749], NNTP COMPRESS has the following advantages: o COMPRESS can be implemented easily both by NNTP servers and clients. o COMPRESS benefits from an intimate knowledge of the NNTP protocol's state machine, allowing for dynamic and aggressive optimization of the underlying compression algorithm's parameters. o COMPRESS can be activated after authentication has completed thus reducing the chances that authentication credentials can be leaked via for instance a CRIME attack ([RFC7457] Section 2.6). [...] 2.2.2. Description [...] Both the client and the server MUST know if there is a compression layer active (for instance via the previous use of the COMPRESS command or the negotiation of a TLS-level compression [RFC3749]). A client MUST NOT attempt to activate compression or negotiate a TLS layer (for instance via the use of the COMPRESS or STARTTLS [RFC4642] commands) if a compression layer is already active. A server MUST NOT return the COMPRESS or STARTTLS capability labels in response to a CAPABILITIES command received after a compression layer is active, and a server MUST reply with a 502 response code if a syntactically valid COMPRESS or STARTTLS command is received while a compression layer is already active. [...] 6. Security Considerations Security issues are discussed throughout this document. In general, the security considerations of the NNTP core specification ([RFC3977] Section 12) and the DEFLATE compressed data format specification ([RFC1951] Section 6) are applicable here. Implementers should be aware that combining compression with encryption like TLS can sometimes reveal information that would not have been revealed without compression, as explained in Section 6 of [RFC3749]. As a matter of fact, adversaries that observe the length of the compressed data might be able to derive information about the corresponding uncompressed data. The CRIME and the BREACH attacks ([RFC7457] Section 2.6) are examples of such case. In order to help mitigate leaking authentication credentials, this document states in Section 2.2.2 that authentication SHOULD NOT be attempted when a compression layer is active. Therefore, when a client wants to authenticate, compress data, and negotiate a secure TLS layer (without TLS-level compression) in the same NNTP connection, it SHOULD use the STARTTLS, AUTHINFO, and COMPRESS commands in that order. Of course instead of using the STARTTLS command, a client can also use implicit TLS, that is to say it begins the TLS negotiation immediately upon connection on a separate port dedicated to NNTP over TLS. NNTP commands other than AUTHINFO are not believed to divulgate confidential information as far as public Netnews newsgroups and articles are concerned. That is why this specification only adds a restriction to the use of AUTHINFO when a compression layer is active. In case private and confidential newsgroups or articles are accessed, a server SHOULD NOT allow compression, and a client SHOULD NOT attempt to activate compression, for the same reasons as mentioned above in this Section. Implementations MUST support a configuration where compression can be easily disabled. Future extensions to NNTP that define commands conveying confidential data SHOULD ensure to state that they SHOULD NOT be used along with compression. Thanks again for your useful comments! -- Julien ÉLIE « Pourvu que ça dure ! » (Letizia Bonaparte) From nobody Fri Jun 10 14:33:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B0412D97D for ; Fri, 10 Jun 2016 14:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2QckBfITmt1 for ; Fri, 10 Jun 2016 14:33:19 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC6C12D97A for ; Fri, 10 Jun 2016 14:33:18 -0700 (PDT) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d42 with ME id 59ZG1t00A17Lgi4039ZGZS; Fri, 10 Jun 2016 23:33:16 +0200 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWVAd2FuYWRvby5mcg== X-ME-Date: Fri, 10 Jun 2016 23:33:16 +0200 X-ME-IP: 92.170.5.52 To: "tls@ietf.org" , uta@ietf.org References: From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <30b54d83-5748-f429-fa20-3b73305b6e3d@trigofacile.com> Date: Fri, 10 Jun 2016 23:33:16 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] [Uta] Compression along with TLS in NNTP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 10 Jun 2016 21:33:20 -0000 > Last year, in September 2015, we spoke about the removal of TLS-level > compression in TLS 1.2. Of course one should read "TLS 1.3". -- Julien ÉLIE « I don't worry about terrorism. I was married for two years. » (Sam Kinison) From nobody Fri Jun 10 15:11:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359F212D98C for ; Fri, 10 Jun 2016 15:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fh2e76BjfJcf for ; Fri, 10 Jun 2016 15:11:13 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 9459212D0C5 for ; Fri, 10 Jun 2016 15:11:13 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id e4so115149193vkb.1 for ; Fri, 10 Jun 2016 15:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=JGy1VdZJYqcgPstN3aKGTlB0eUhfkJP57tZ0N0YC+OE=; b=KYh5BxyLQyr/S36LTvsYRon3ASZYTkQsS6LiELu2vmSJsTldhRsok+oYPNJlGBPs+u 5rm+j494BpNx34Bxc1EbWixza6yorrdrxfFTKKjoUyKIuGvSW4wHTyDOUH5SyMxjIDLy 5Rpi7Kg4bjVhGvtwsf10OoBqBFQ/XTORUmmqucmnZmrKcCXBPNWDM9T+3rbn2eQEmOJ3 D0qNnTNk9p1OA0scIToZSdJ28ZnPPbEf86FwYdlFxY04bHIw/zO9vFDz8OxXpVw3C/U/ BTp9u7SaaA3D3B/1iFSE4z1nMDtM10ZJJHt/WfG0pEO4agyO92e1qEGZzLph19Btkb5U 3Ndg== 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; bh=JGy1VdZJYqcgPstN3aKGTlB0eUhfkJP57tZ0N0YC+OE=; b=ft8uUO0Q/50Oq2vUFCbp3Ozsus+cztHFiDKHtBvwbt3qa+Sic9Ur4J7bnvI9OqatY8 BLedBH9CAv3wzGlnA4McXUc/G+8LFNKxh1pc3Xcb9n66WeAXJDoqVzBF3k8IzUh1XaVW NkO7APzzOSWg6igjrXmsD4KLBw6XxRPXc0Lu0wv1WtdaRS551+HA4YwiSvgdqs3vUCBA pfKLXxPXIX9CSyJLAEQVkKT05R6iyMmlJ1RjL9F0ix1osyIbOzFAKl33D9ZE5qmlVUx+ nvhUujWrZQbqUWVIaG8wWV2Uf85cytNrKNu4ssimzevJm/d3m3uDVdu5hf3aqu1mCJLu bhzQ== X-Gm-Message-State: ALyK8tJB7MPLTKekyuN07hZZuQa49ED1s7biK2W4k7LDzlC/t9xwMfQnQClp1LGBI3NSr7du+nXPgGZFVRGq0A== MIME-Version: 1.0 X-Received: by 10.159.34.19 with SMTP id 19mr1907650uad.21.1465596672729; Fri, 10 Jun 2016 15:11:12 -0700 (PDT) Received: by 10.103.49.193 with HTTP; Fri, 10 Jun 2016 15:11:12 -0700 (PDT) In-Reply-To: <2144997004.41497030.1465551066584.JavaMail.zimbra@redhat.com> References: <19D9A152-3801-44DA-ADF0-345011EDF54D@gmail.com> <4418055.GXTqvqFNm1@pintsize.usersys.redhat.com> <60729080-E56E-41D5-AAB0-FAD46FCE1C00@gmail.com> <2144997004.41497030.1465551066584.JavaMail.zimbra@redhat.com> Date: Fri, 10 Jun 2016 18:11:12 -0400 Message-ID: From: Tony Arcieri To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=001a1137d4ae0feddb0534f3d1fa Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 10 Jun 2016 22:11:15 -0000 --001a1137d4ae0feddb0534f3d1fa Content-Type: text/plain; charset=UTF-8 On Friday, June 10, 2016, Nikos Mavrogiannopoulos wrote: > I'm actually surprised you mention the microsoft servers as being > version negotiation tolerant. They were the most prominent examples > of terminating the handshake if TLS 1.2 was offered to them > Personally I'd give that award to F5 BIG-IP devices -- Tony Arcieri --001a1137d4ae0feddb0534f3d1fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Friday, June 10, 2016, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
I'm actually surprised you mention the microsoft servers as being version negotiation tolerant. They were the most prominent examples
of terminating the handshake if TLS 1.2 was offered to them

Personally I'd give that award to F5 B= IG-IP devices=C2=A0


--
Tony Arcieri

--001a1137d4ae0feddb0534f3d1fa-- From nobody Sun Jun 12 06:54:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704E312D192 for ; Sun, 12 Jun 2016 06:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3anHbJ0Ndgln for ; Sun, 12 Jun 2016 06:54:00 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2110312B015 for ; Sun, 12 Jun 2016 06:53:59 -0700 (PDT) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d50 with ME id 5ptJ1t00E17Lgi403ptJpT; Sun, 12 Jun 2016 15:53:58 +0200 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWVAd2FuYWRvby5mcg== X-ME-Date: Sun, 12 Jun 2016 15:53:58 +0200 X-ME-IP: 92.170.5.52 To: uta@ietf.org, "tls@ietf.org" References: <1465697482.2175.38.camel@16bits.net> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <50a50403-554e-e9c9-2053-ecc33fba55ae@trigofacile.com> Date: Sun, 12 Jun 2016 15:53:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1465697482.2175.38.camel@16bits.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: =?UTF-8?Q?=c3=81ngel_Gonz=c3=a1lez?= Subject: Re: [TLS] [Uta] Compression along with TLS in NNTP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2016 13:54:02 -0000 Hi Ãngel, > The main problem is not as much that the contents are compressed or > not, but that known plain text and confidential data are compressed > together. > > As such, I don't think it's usually necessary to disable it for > confidential articles/newsgroups. First of all, thanks for your valuable comment. I will take it into account in the wording of the draft. > Regarding your draft, I would > a) add a None algorithm > b) allow compress to be called inside a compress session, replacing the > previous one. > > Thus, a client would be able to COMPRESS DEFLATE, , > COMPRESS NONE, , COMPRESS DEFLATE, activity> > > Or even call COMPRESS DEFLATE, , COMPRESS DEFLATE, > to ensure their contents are not compressed together. I understand the scenario. It implies here that the client will have to know somehow what kinds of newsgroups or articles need extra-security. The client will have to send the right COMPRESS commands at the right time. Wouldn't it be better that the server also knows somehow what kinds of newsgroups or articles need extra-security, and clears the compression dictionary even if not explicitly asked by the client? We could otherwise have a situation where not all the clients accessing secret articles are correctly configured. Therefore, one of the clients may leak information. If both the client and the server ensure not to compress public and confidential data together, it would be better, wouldn't it? Hmm, on second thoughts, this suggestion of a None algorithm and allowing to switch to another algorithm at any time adds complexity that could be avoided by another suggestion: if a client wants to access both public groups and secret articles, why not open two separate NNTP connections (either in parallel or one after the other)? These two sessions can be compressed, and there will be no leakage. So as to answer your proposal of ensuring that the contents of articles are not compressed together, we could call "COMPRESS DEFLATE FLUSH" (or another better optional argument) that asks the server to clear the compression dictionary after every response. -- Julien ÉLIE « Ta remise sur pied lui a fait perdre la tête ! » (Astérix) From nobody Sun Jun 12 08:53:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3C212D5C8; Sun, 12 Jun 2016 08:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CE3XsHKtQeO; Sun, 12 Jun 2016 08:53:44 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 6274C12D5AD; Sun, 12 Jun 2016 08:53:44 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id e5so27873606ith.0; Sun, 12 Jun 2016 08:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mGtXgv8s6UoC/YIqRlAFwsr6gvy0D52YqEiKoc0Ca1A=; b=VOwgd187BxVgsFbum+ARxDYcU99unXWGljkq4fLB6JW1ycqegB7VonDbVrKQ8wuKnj Nio3a2XfExXnLVzo1w1imWTgBi523FvPktQOpHRJmbXjzBj1Ey2eV52AGMJ5bu0owQCd TEtMI6e77P7E6kKzLZLYNHx4OJnD/GQQfwfGE3CjJ5E7NuoCOCTyJW6o67hyGF3BV0v5 uv1euJw61kZXq/9hPGRqjHBU9ZmSJe1PvGmEx9vvHjygWtuuwRFJTdPKOtxvylAC20DL cviPIZOxe0mS+8I7sWF+eDRYw5l3SMDNKBm6zuQPwArTUD98Js8jBGC+vVU3OP606dnW YxMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=mGtXgv8s6UoC/YIqRlAFwsr6gvy0D52YqEiKoc0Ca1A=; b=IXLYaS0hybRZrl7akX0J3/D2E4lw7V5Zl9h1oMV31bq6I1M4xHMfWBv1IdQpAtkTBP 9E63GmqgHZ2FXS5aHl7OCkLGGKhSgm39QpWIP36RxljzthhU4K1kMO0uuyhyTBpUYOkT Hb+62H+2iTtbHcd26aQmSLyvwmMQKyyhUbI/oLUXs8dt+WH+5mM8p+ft+pdiVY0L33+A sfjVQ8dbburZy02douzgr1uozXKpstT+qajp6i2+he/XBx73UGPxR/PkemP5XyFi5cPk EisxStO+/Hpemxn2gQgqXzeg7cLAYZ+ZASZ1ICcP1Hb9YVsfo33qUSgD3ntjzK019Qwz 3ZiQ== X-Gm-Message-State: ALyK8tI5gcEkYMcTXdXvB1BGb2inCMowzG14ssPjKYmKChKqufRs/tOFxL/J32zyqy+1x/TmVSMDrbas5ZSjCw== X-Received: by 10.36.76.71 with SMTP id a68mr5325510itb.77.1465746823680; Sun, 12 Jun 2016 08:53:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.162.132 with HTTP; Sun, 12 Jun 2016 08:53:43 -0700 (PDT) In-Reply-To: References: From: Jeffrey Walton Date: Sun, 12 Jun 2016 11:53:43 -0400 Message-ID: To: =?UTF-8?B?SnVsaWVuIMOJTElF?= Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: uta@ietf.org, "tls@ietf.org" Subject: Re: [TLS] Compression along with TLS in NNTP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 12 Jun 2016 15:53:46 -0000 > Here is an extract of the paragraphs dealing with TLS in the draft, so that > you can easily see what to comment (wording improvement, missing stuff...). > > The point of COMPRESS as an NNTP extension is to behave as a > transport layer, similar to STARTTLS [RFC4642]. Compression can > therefore benefit to all NNTP commands sent or received after the use > of COMPRESS. It kind of sounds doomed under threat models with active attackers. The active attacker can swallow the STARTTLS message and no one would be the wiser. How does the protocol thwart downgrades under active attackers? Jeff From nobody Sun Jun 12 12:17:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F49612D629 for ; Sun, 12 Jun 2016 12:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8wxtHEgFoYW for ; Sun, 12 Jun 2016 12:17:08 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273F812D176 for ; Sun, 12 Jun 2016 12:17:08 -0700 (PDT) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d27 with ME id 5vH51t00617Lgi403vH5ic; Sun, 12 Jun 2016 21:17:06 +0200 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWVAd2FuYWRvby5mcg== X-ME-Date: Sun, 12 Jun 2016 21:17:06 +0200 X-ME-IP: 92.170.5.52 References: To: uta@ietf.org, "tls@ietf.org" From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <4f853488-185d-73a1-a2c0-dec0bdf7a79c@trigofacile.com> Date: Sun, 12 Jun 2016 21:17:05 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] [Uta] Compression along with TLS in NNTP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2016 19:17:10 -0000 Hi Jeffrey, >> Here is an extract of the paragraphs dealing with TLS in the draft, so that >> you can easily see what to comment (wording improvement, missing stuff...). >> >> The point of COMPRESS as an NNTP extension is to behave as a >> transport layer, similar to STARTTLS [RFC4642]. Compression can >> therefore benefit to all NNTP commands sent or received after the use >> of COMPRESS. > > It kind of sounds doomed under threat models with active attackers. > The active attacker can swallow the STARTTLS message and no one would > be the wiser. > > How does the protocol thwart downgrades under active attackers? First of all, one should note that STARTTLS is not widely used in practice for NNTP. Implicit TLS on a dedicated port (TCP 563) is the common way for NNTP clients to negotiate a TLS layer. To answer your question, the Security Considerations Section of RFC 4642 (Using TLS with NNTP) mentions: Before the TLS handshake has begun, any protocol interactions are performed in the clear and may be modified by an active attacker. For this reason, clients and servers MUST discard any sensitive knowledge obtained prior to the start of the TLS handshake upon the establishment of a security layer. Furthermore, the CAPABILITIES command SHOULD be re-issued upon the establishment of a security layer, and other protocol state SHOULD be re-negotiated as well. [...] During the TLS negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. Matching is performed according to these rules: - The client MUST use the server hostname it used to open the connection (or the hostname specified in TLS "server_name" extension [TLS-EXT]) as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done. - If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity. - Matching is case-insensitive. - A "*" wildcard character MAY be used as the left-most name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc., but would not match example.com. - If the certificate contains multiple names (e.g., more than one dNSName field), then a match with any one of the fields is considered acceptable. If the match fails, the client SHOULD either ask for explicit user confirmation or terminate the connection with a QUIT command and indicate the server's identity is suspect. Additionally, clients MUST verify the binding between the identity of the servers to which they connect and the public keys presented by those servers. Clients SHOULD implement the algorithm in Section 6 of [PKI-CERT] for general certificate validation, but MAY supplement that algorithm with other validation methods that achieve equivalent levels of verification (such as comparing the server certificate against a local store of already-verified certificates and identity bindings). A man-in-the-middle attack can be launched by deleting the STARTTLS capability label in the CAPABILITIES response from the server. This would cause the client not to try to start a TLS session. Another man-in-the-middle attack would allow the server to announce its STARTTLS capability, but alter the client's request to start TLS and the server's response. An NNTP client can partially protect against these attacks by recording the fact that a particular NNTP server offers TLS during one session and generating an alarm if it does not appear in the CAPABILITIES response for a later session. (Of course, the STARTTLS capability would not be listed after a security layer is in place.) If the client receives a 483 or 580 response, the client has to decide what to do next. The client has to choose among three main options: to go ahead with the rest of the NNTP session, to (re)try TLS later in the session, or to give up and postpone newsreading/transport activity. If an error occurs, the client can assume that the server may be able to negotiate TLS in the future and should try to negotiate TLS in a later session. However, if the client and server were only using TLS for authentication and no previous 480 response was received, the client may want to proceed with the NNTP session, in case some of the operations the client wanted to perform are accepted by the server even if the client is unauthenticated. Does it answer your question? -- Julien ÉLIE « Contra factum non datur argumentum. » From angel@ietf.16bits.net Sat Jun 11 19:08:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9D112D103; Sat, 11 Jun 2016 19:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGE63agGMww9; Sat, 11 Jun 2016 19:08:33 -0700 (PDT) Received: from mailer.hiddenmail.net (mailer.hiddenmail.net [199.195.249.9]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25F012B057; Sat, 11 Jun 2016 19:08:33 -0700 (PDT) Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from ) id 1bBupD-0001Td-0h; Sun, 12 Jun 2016 04:08:31 +0200 Message-ID: <1465697307.2175.32.camel@16bits.net> From: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= To: Julien =?ISO-8859-1?Q?=C9LIE?= , "tls@ietf.org" , uta@ietf.org Date: Sun, 12 Jun 2016 04:08:27 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.20.2 Mime-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sun, 12 Jun 2016 20:12:10 -0700 Subject: Re: [TLS] [Uta] Compression along with TLS in NNTP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2016 02:16:38 -0000 On 2016-06-10 at 22:43 +0200, Julien =C3=89LIE wrote: > NNTP commands other than AUTHINFO are not believed to divulgate > confidential information as far as public Netnews newsgroups and > articles are concerned.=C2=A0=C2=A0That is why this specification only ad= ds a > restriction to the use of AUTHINFO when a compression layer=20 > active.=C2=A0=C2=A0In case private and confidential newsgroups or article= s are > accessed, a server SHOULD NOT allow compression, and a client SHOULD > NOT attempt to activate compression, for the same reasons as > mentioned above in this Section. >=20 > Implementations MUST support a configuration where compression can be > easily disabled. >=20 > Future extensions to NNTP that define commands conveying confidential > data SHOULD ensure to state that they SHOULD NOT be used along with > compression. >=20 > Thanks again for your useful comments! The main problem is not as much that the contents are compressed or not, but that known plain text and confidential data are compressed together. As such, I don't think it's usually necessary to disable it for confidential articles/newsgroups. What you need to avoid is that in the same compress session where you read the article with the steps to enter into the nuclear facility, you also read a different public article that the spies know you will read, as the compressed size will vary depending on the contents of the secret. Of course, if instead of a general text of relatively unknown length, the attacker knows that you will get a list of 100 nuclear launch codes, seeing how well did it compress might allow them to guess some of their properties. Regarding your draft, I would=C2=A0 a) add a None algorithm b) allow compress to be called inside a compress session, replacing the previous one. Thus, a client would be able to COMPRESS DEFLATE, , COMPRESS NONE, , COMPRESS DEFLATE, Or even call COMPRESS DEFLATE, , COMPRESS DEFLATE, to ensure their contents are not compressed together. Best regards From nobody Sun Jun 12 20:12:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8539712D5D8 for ; Sun, 12 Jun 2016 17:05:57 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 09 hex): References: ...fdfae2d@trigofacile.com>\n\t\n <1465697482.2[...] 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GioTY9j-EivO for ; Sun, 12 Jun 2016 17:05:56 -0700 (PDT) Received: from mailer.hiddenmail.net (mailer.hiddenmail.net [199.195.249.9]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3315512D111 for ; Sun, 12 Jun 2016 17:05:55 -0700 (PDT) Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from ) id 1bCFO5-0007aK-1f; Mon, 13 Jun 2016 02:05:53 +0200 Message-ID: <1465776350.6588.22.camel@16bits.net> From: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= To: Julien =?ISO-8859-1?Q?=C9LIE?= , "tls@ietf.org" , uta@ietf.org Date: Mon, 13 Jun 2016 02:05:50 +0200 In-Reply-To: <50a50403-554e-e9c9-2053-ecc33fba55ae@trigofacile.com> References: <1465697482.2175.38.camel@16bits.net> <50a50403-554e-e9c9-2053-ecc33fba55ae@trigofacile.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.20.2 Mime-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sun, 12 Jun 2016 20:12:10 -0700 Subject: Re: [TLS] [Uta] Compression along with TLS in NNTP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2016 00:05:57 -0000 On 2016-06-12 at 15:53 +0200, Julien =C3=89LIE wrote: > Hi =C3=81ngel, >=20 > First of all, thanks for your valuable comment.=C2=A0=C2=A0I will take it= into=C2=A0 > account in the wording of the draft. >=20 Hello Julien You are welcome > I understand the scenario. > It implies here that the client will have to know somehow what kinds > of newsgroups or articles need extra-security.=C2=A0=C2=A0The client will= have > to send the right COMPRESS commands at the right time. Yes. Take into account that often only the client will be able to know if the newsgroup contents are deemed confidential by the user or not. > Wouldn't it be better that the server also knows somehow what kinds > of newsgroups or articles need extra-security, and clears the > compression dictionary even if not explicitly asked by the client? Of course, the server MAY flush the compression dictionary more often than required to satisfy some security properties (assuming that's supported by the algorithm). > We could otherwise have a situation where not all the clients > accessing secret articles are correctly configured.=C2=A0=C2=A0Therefore,= one > of the clients may leak information.=C2=A0=C2=A0If both the client and th= e > server ensure not to compress public and confidential data together, > it would be better, wouldn't it? No objection to that. > Hmm, on second thoughts, this suggestion of a None algorithm and=C2=A0 > allowing to switch to another algorithm at any time adds complexity=20 I expect it isn't too much. It's basically the same operation of switching into compressed or encrypted. Moreover, it's easier to verify that the compressor is properly flushed, as the state is completely reinitialised. > that could be avoided by another suggestion:=C2=A0=C2=A0if a client wants= to > access both public groups and secret articles, why not open two > separate NNTP connections (either in parallel or one after the > other)?=C2=A0=C2=A0These two sessions can be compressed, and there will b= e no > leakage. You are sending a stronger signal to someone that was watching the connection, as he will be able to see the two connections. Plus, that requires more server resources (supporting several connections per client) and there is an added overhead of STARTTLS + AUTH on the new connection. For the client wishing to implement this, it may encounter itself being throttled or limited to 1 connection to the server per IP. > So as to answer your proposal of ensuring that the contents of > articles are not compressed together, we could call "COMPRESS DEFLATE > FLUSH" (or another better optional argument) that asks the server to > clear the compression dictionary after every response. I expect it to have a similar complexity as allowing a complete algorithm change, while being more limited. What if eg. the user wanted to authenticate again with a different set of credentials? Best regards From nobody Mon Jun 13 12:00:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBBC12D698 for ; Mon, 13 Jun 2016 12:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5lvl1-MskQ9 for ; Mon, 13 Jun 2016 12:00:27 -0700 (PDT) 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 5A66012D0B0 for ; Mon, 13 Jun 2016 12:00:23 -0700 (PDT) Received: by mail-qg0-x22e.google.com with SMTP id v76so41169911qgv.3 for ; Mon, 13 Jun 2016 12:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=XgLT0541gesugnj7/MyjlDUcM0hPP4fJ///Yvuf7tRs=; b=WnJ9FrRBOUQ+XDedYXNx54Yn1uZNFwN6FtJc72LrYO9nGO3XmczU4VV/xUMUqegvhq EnYHbZm5IzIFuZe3q3x1UmFNfFAw+2+hchyuFWhYZTgjesitvI/37VTvO5IhE3j8ytdt /HPqtI79t1P3/Y19ttseXFa2l5lwd1o9MO6Jz4at40yUUgsOBuUkSKnHucFO6SzQg+eo LqlNe7QtF+UccxtFU2dZmls6hWLE9trISKwEraIPL+kFu7OL76tTS2G5qKwxNZLJqYGW ftm83pFVKYxpjuBgAvtlAGtAw4tmjl1ZrxGoOoXD0UEsa+vT7ZSeMmy7BXpapWyinFB9 EwVg== 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; bh=XgLT0541gesugnj7/MyjlDUcM0hPP4fJ///Yvuf7tRs=; b=R/0AQyPYqoSgJrdA84YzdO02lLGF4OhZhc+BOdlu5luvVlnGFkgzQLg1I7ixMOgNoP d3wulygDDfcSFcFyo4XWx/YoJCUxOiAOuk2cMacFMUQ8Ya6Mw4uLBeGh/3cKFprZUt0d 9MjBi7sm6HGOW3oJj2R99iVEWEj2pucwCMYcw+GRZIV1SochteiJL3jtcCJk21ud2/pZ W1G7w/emEh0QNQGPLTXwUaCtThFDn6uzcBeW7KREUMzkd925ddHGluzKO9F8CAgtZnL1 1XPnzXCmawyBA/UJswigP2ubti3qzbmFRklT0nhhLhc5BlPgMHqXH7MzJltcAOCv1yyK jtyQ== X-Gm-Message-State: ALyK8tKRFOHN97h/t+6TVVVn3e6+CQl9g20O26I5/dlKu1NOqcJnck9Xg/7tAIFormYDfRrB9Ca4KXDPVg17vQ== X-Received: by 10.140.19.231 with SMTP id 94mr15778014qgh.39.1465844422530; Mon, 13 Jun 2016 12:00:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.181.134 with HTTP; Mon, 13 Jun 2016 12:00:03 -0700 (PDT) From: Joseph Salowey Date: Mon, 13 Jun 2016 12:00:03 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1134edfa1a021c05352d807c Archived-At: Subject: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2016 19:00:31 -0000 --001a1134edfa1a021c05352d807c Content-Type: text/plain; charset=UTF-8 For background please see [1]. Please respond to this message indicating which of the following options you prefer by Monday June, 20, 2016 1. Use the same key for handshake and application traffic (as in the current draft-13) or 2. Restore a public content type and different keys Thanks, J&S [1] https://www.ietf.org/mail-archive/web/tls/current/msg20241.html --001a1134edfa1a021c05352d807c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For background please see [1].

Please= respond to this message indicating which of the following options you pref= er by Monday June, 20, 2016=C2=A0

1. Use the= same key for handshake and application traffic (as in the current draft-13= )

or

=
2. Restore a public content type and different ke= ys

Thanks,
--001a1134edfa1a021c05352d807c-- From nobody Mon Jun 13 12:47:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DB612D99C for ; Mon, 13 Jun 2016 12:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.226 X-Spam-Level: X-Spam-Status: No, score=-4.226 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xgekSkz13ec for ; Mon, 13 Jun 2016 12:47:18 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9617712D9B0 for ; Mon, 13 Jun 2016 12:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1465847234; x=1497383234; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GaXQjrVfc9GiDAZATzS03Fc3b/+m9Wdh0Y7WIY74NTY=; b=J1OQd9t1UGqbINv8oqgLVQY9psdvipHmJElYb1jqXrWi5vGHiwpDkhhd tkCuNfuUIXw/nA+fXm5WW/DrKPdSIA1UMvhr+SR6+enhQacHvITxdLA30 kBtul046UvBaOrqBfvD6ronAh1bzlKUApq5lb5PbAj/nox1wcLrRq3jCJ R3WUkwmd/Ura6ggOKpkDd/c9Fdnyx7XL/BoHC3Y/icVCMzN9upFtMmW42 K2tr5Ajkk+Jg8HWTw1CbcsD8WITtfQ2ILstMF+8amxlHj3/qLSXe//T4x yWR3x2XCnU3BVLQsH/wv1Q/wU1ghmJg1ZEGmlSrUsTsr/3HgZrzMeJCCx A==; X-IronPort-AV: E=Sophos;i="5.26,467,1459771200"; d="scan'208";a="91156972" 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; 14 Jun 2016 07:47:10 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Tue, 14 Jun 2016 07:47:10 +1200 From: Peter Gutmann To: Hubert Kario Thread-Topic: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] Thread-Index: AQHRwMgFSc+0J48oU0SuzFcIH2kf65/dSI8AgANVHXT//358gIAHuuN8 Date: Mon, 13 Jun 2016 19:47:09 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CA0C84@uxcn10-5.UoA.auckland.ac.nz> References: <2698023.3YM6Cv9mer@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C9E452@uxcn10-5.UoA.auckland.ac.nz>, <2728571.M7U9SoToVs@pintsize.usersys.redhat.com> In-Reply-To: <2728571.M7U9SoToVs@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: [10.6.3.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2016 19:47:24 -0000 Hubert Kario writes:=0A= =0A= >run _everything_ is not really possible as some tests actually require=0A= >mutually exclusive server settings - e.g. some require the server not to a= sk=0A= >for client certificate while others do=0A= =0A= Ah, OK.=0A= =0A= >finally, while I do look forward to any contributions (just ideas for test= s=0A= >would be huge help!) I do want the tool to be as platform independent as= =0A= >possible (require just Python runtime, be it 2.6, 3.5 or anything in-=0A= >between), so if you do plan to write the script, may I ask you to do that = in=0A= >python too?=0A= =0A= I don't really speak python, it was just a quick "for f in *.py do ... done= ",=0A= I was just checking whether there was something less crude available.=0A= =0A= Peter.= From nobody Mon Jun 13 12:53:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550B712D123 for ; Mon, 13 Jun 2016 12:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gezxGHOtCrH for ; Mon, 13 Jun 2016 12:51:46 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A95B12D9AC for ; Mon, 13 Jun 2016 12:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1465847505; x=1497383505; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=19ioOQgeVbAmQL27h/9U9tYK/D8idcrd1I/Qs3B0bN8=; b=mkglHa3Wf1OtQPaV5J26UMiKIpq4D8zm20aXqycvyoX+1DjoBxj1m6xl kRqhH0TjxPsjD05n4y56IeGXXxuR0KJ7N7MJeUgBVxefhvhssTy5/+Ats OSaeMFgI58QrdjYxot+V1yNzDk+4EhjpsuOpYsW4KYU1G30ywg5PyM9xO kHpSEw4GfVvPQ44zStVClCkVSbYPulPubyjt3zpC66EJH+Ee6SCiF2jWA KjTGHjSrXDaR8MDckXZKOUTpMmmMxEGWCwpuhzHF8XRkyYsIV0mjGIcFh 1mHtEOZubdfkN3x4ywsT93SxHBVd0ddRNf67RDvwKFXwppnLAT56nUYYu w==; X-IronPort-AV: E=Sophos;i="5.26,467,1459771200"; d="scan'208";a="91157340" 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; 14 Jun 2016 07:51:44 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Tue, 14 Jun 2016 07:51:44 +1200 From: Peter Gutmann To: Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] Adoption of TLS-LTS Thread-Index: AdG/9CVqy8MYXur6TqWx/88FbT3L7gBWWRwAABuaKxIABSL9gAD3FFPH Date: Mon, 13 Jun 2016 19:51:42 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CA0C94@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C9CA49@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C9E044@uxcn10-5.UoA.auckland.ac.nz>, <22902566.AuEvmjhU12@pintsize.usersys.redhat.com> In-Reply-To: <22902566.AuEvmjhU12@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: [10.6.3.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Adoption of TLS-LTS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2016 19:53:02 -0000 Hubert Kario writes:=0A= =0A= >to be pedantic, the RFC describes itself "a profile" while in reality it= =0A= >modifies the protocol in a way that will make it incompatible with "vanill= a"=0A= >TLS 1.2 implementations=0A= =0A= >to be pedantic, the RFC describes itself "a profile" while in reality it= =0A= >modifies the protocol in a way that will make it incompatible with "vanill= a"=0A= >TLS 1.2 implementations=0A= =0A= Oh, right. Well that's easily fixed, I used "profile" because I couldn't= =0A= think of a better term, the best I could come up with is "plan", but it's n= ot=0A= really a plan either. If people think "plan" is better than "profile", and= it=0A= deals with Russ' objection, I'll change it to that. Alternatively, if you = can=0A= think of a better term than "plan", let me know (or forever hold your peace= =0A= :-).=0A= =0A= Peter.= From nobody Mon Jun 13 13:27:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D325A12D9D5 for ; Mon, 13 Jun 2016 13:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVXmC_86QrJ5 for ; Mon, 13 Jun 2016 13:27:56 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA7312D660 for ; Mon, 13 Jun 2016 13:27:25 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id A92E0F98B; Mon, 13 Jun 2016 16:27:24 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 07D8822AFF; Mon, 13 Jun 2016 16:27:24 -0400 (EDT) From: Daniel Kahn Gillmor To: Joseph Salowey , "tls\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.22+69~gd812194 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Mon, 13 Jun 2016 16:27:23 -0400 Message-ID: <8760tc3kd0.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2016 20:27:58 -0000 On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: > 1. Use the same key for handshake and application traffic (as in the > current draft-13) > > or > > 2. Restore a public content type and different keys Given this choice, i prefer (1). --dkg From nobody Mon Jun 13 13:35:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E40412DA01 for ; Mon, 13 Jun 2016 13:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CXvcLhSbzr9 for ; Mon, 13 Jun 2016 13:35:22 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 5C45A12D9FC for ; Mon, 13 Jun 2016 13:34:58 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id z186so118780923ywd.2 for ; Mon, 13 Jun 2016 13:34:58 -0700 (PDT) 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; bh=DYwDeAZ6R/HqOREpSjCV3fdn2GNnVClRCNLqarmwLCQ=; b=vcozaRGtFk67up1ECNEBcMpc87NnmMAoAWGZTQJMn3Dgrfms9Ny5jyUQJMrSUAtRRF 9iyRMQGPvZP3m1dv6RrCqRZNtYItjRN9CGvGYPg3OVOxgqp1o23Vogn9ozONZxr/2931 P4XX404eZqptbGMHFzPI8ysAUHUwgFgnaB7wwp3ypzmi8SXOzqi/2MSFS0sbBpl+4Q2p a+8DM73fjSWSoObGyl2esBG8PlvWa7nxqOcozzjpDByPVhfGOko2OPnHjOx3Wh3ZVCJP VwLRa2MGCq+9U7GaiVayhEOgoANyVlg0kYuuafsrRx4bPxOymWkIXFQCxhdV3SGZtQfo /JfA== 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; bh=DYwDeAZ6R/HqOREpSjCV3fdn2GNnVClRCNLqarmwLCQ=; b=dhq62Ko/+ZMpqi9yso1ThbVF1vTigqzd6X0CsPQe0eJ4k+6yFMVvHjyqMckGBpCvb3 S9OJQlhUTrO17vS9DGcWVrRuVwSeV/QFkY7SgydoZv9qqYDsWaeoDIIJxUVtYTL+B4fz C5IXDVAnwe2qdNxCaXyvhoVFalu/fhwxBlEYv8SbhiU/hgd+FHT99eN7ZDgj4FR5b8ZL AkkVH35i3KGW95z4rjCwahvgt0QWF9+g1ERq2VJ+nlJSgY5SDjY1G0Eq0kJebgmbNi8K /zty6iuKQH+oLoH3gio3xVzuhu8jWqwY3uuoMHZPW9iPQoUxm9poLTAHrg4on3gG1VI9 gGrQ== X-Gm-Message-State: ALyK8tLXQYPgas5KxG51At677t8VvjtbzWBMsu7HLXOMLc4FPa3JX8DaeHiUJlLE9IA93vKzGgS49mTWPVeklQ== X-Received: by 10.37.229.194 with SMTP id c185mr8225799ybh.146.1465850097636; Mon, 13 Jun 2016 13:34:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.213.206 with HTTP; Mon, 13 Jun 2016 13:34:18 -0700 (PDT) In-Reply-To: <8760tc3kd0.fsf@alice.fifthhorseman.net> References: <8760tc3kd0.fsf@alice.fifthhorseman.net> From: Eric Rescorla Date: Mon, 13 Jun 2016 21:34:18 +0100 Message-ID: To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=94eb2c086de85d482205352ed246 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2016 20:35:24 -0000 --94eb2c086de85d482205352ed246 Content-Type: text/plain; charset=UTF-8 +1 On Mon, Jun 13, 2016 at 9:27 PM, Daniel Kahn Gillmor wrote: > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: > > 1. Use the same key for handshake and application traffic (as in the > > current draft-13) > > > > or > > > > 2. Restore a public content type and different keys > > Given this choice, i prefer (1). > > --dkg > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c086de85d482205352ed246 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Mon, Jun 13, 2016 at 9:27 PM, Daniel Kahn Gillmor <dkg@fift= hhorseman.net> wrote:
On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:
> 1. Use the same key for handshake and application traffic (as in the > current draft-13)
>
=C2=A0> or
>
> 2. Restore a public content type and different keys

Given this choice, i prefer (1).

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

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

--94eb2c086de85d482205352ed246-- From nobody Mon Jun 13 22:08:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6B412D59F for ; Mon, 13 Jun 2016 22:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7pv5xaltywF for ; Mon, 13 Jun 2016 22:08:05 -0700 (PDT) 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 3216912D5F9 for ; Mon, 13 Jun 2016 22:08:04 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id m124so105458792wme.1 for ; Mon, 13 Jun 2016 22:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yyPGeVBY/83tY2I4xsdYCgYXvAHtBMdV0mhu4c8o0AQ=; b=keyhN1tFOwFacpQpYZTM6qCCyWQonvs0FaG6Gw0oI+uvr8cxxeuBuE4koYrsLYtrA+ U/LznXFTicH0humv84zLjFXfMEXZXxjJre/3DM0ZNi+bW7A/jn2bTwqgAvfVid+SGm81 W/ctMZ/xYQevQkaQ6uiu7fHc92BYgzbhkCkiIy5xQ48nOGEosGjbOyiU5Go1BZP1e838 LIT4iozgYbHzDdmtA6vMRea7hZcsf2SSZOZZeqQAXK4UAf2hnE39buCml61H3EwtR3pi F+9BoRlA0Sdt0WFtuBLV+H8WT32P8WS2P21/s64oZWPde2vNlMFUUziteEK958WAngDa n6qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yyPGeVBY/83tY2I4xsdYCgYXvAHtBMdV0mhu4c8o0AQ=; b=m1wPMwmVxDMbV5543JD746LLkvuQfyv23/SW20kV8YzI6dFDkBtNaEnvAoI/QvVaGl BtoztxqIdreBr7cZ4PPu8pLBg/msTRSRC6nTjxsRYATnEjw/BVo+l31SeKgF1MbJNyIz caOEuwlZY1weXJC91T4KZgC12V0ohIWucxrJycrnn/GNd5s4ZJpu0IjuNS3q6eP2tUsb T/13Cwq02Z8wbcVwwqPk+kWeuTINpeZK6fFiYBjDskc1b0wXL4LHpYwzB0QUHygP1X01 hfUBbhP4UP/ILBlW0h/1qUxwtQoW4jlwh+mUXGTBPQOBoE/1DAuFPaM9BLblsAwB2Vqa KmXQ== X-Gm-Message-State: ALyK8tL/vne/wKU55CU5EiP0RYTApkyLCOZz7bNPQX+/7zTS6DDg4F+B+vmXUom0o9KUSA== X-Received: by 10.28.132.201 with SMTP id g192mr4325472wmd.87.1465880882656; Mon, 13 Jun 2016 22:08:02 -0700 (PDT) Received: from [192.168.0.51] (89-156-8-219.rev.numericable.fr. [89.156.8.219]) by smtp.gmail.com with ESMTPSA id kd7sm30848669wjc.33.2016.06.13.22.08.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Jun 2016 22:08:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Karthikeyan Bhargavan In-Reply-To: <8760tc3kd0.fsf@alice.fifthhorseman.net> Date: Tue, 14 Jun 2016 07:08:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B833484-DFD8-419A-877C-C1F259AC4528@gmail.com> References: <8760tc3kd0.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 05:08:07 -0000 I prefer (2) > On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor = wrote: >=20 > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: >> 1. Use the same key for handshake and application traffic (as in the >> current draft-13) >>=20 >> or >>=20 >> 2. Restore a public content type and different keys >=20 > Given this choice, i prefer (1). >=20 > --dkg >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jun 13 22:23:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCC712D0D8 for ; Mon, 13 Jun 2016 22:23:53 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_5UKOGcsnlb for ; Mon, 13 Jun 2016 22:23:51 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E6112D103 for ; Mon, 13 Jun 2016 22:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QuFROHBL9G4l6thW21Jb8GRxv6H1rGynawIbqMcRz3E=; b=lPyT2vxif4GcbXJHwxNU3N9o3aFvoVj9cXXBKzEa+dl7hoj1kLfsLtUXoOchYYaLGvHWt9xgc5mLuibRo18ZpFeotKTBaGBFg1Pr230rr3spBeyfoK40NpOGagmB9C9ZIKdKiqZkSEuUrnXxENeGqvzVLuujtmP9udr8yZDl6ys= Received: from BN3PR03MB1445.namprd03.prod.outlook.com (10.163.34.28) by BN3PR03MB1447.namprd03.prod.outlook.com (10.163.34.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Tue, 14 Jun 2016 05:23:31 +0000 Received: from BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) by BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) with mapi id 15.01.0517.009; Tue, 14 Jun 2016 05:23:31 +0000 From: Andrei Popov To: Joseph Salowey , "tls@ietf.org" Thread-Topic: [TLS] Consensus call for keys used in handshake and data messages Thread-Index: AQHRxaXnd1+1nm92PUe7AUdKIO7TFJ/obc/A Date: Tue, 14 Jun 2016 05:23:30 +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=Andrei.Popov@microsoft.com; x-originating-ip: [50.46.229.189] x-ms-office365-filtering-correlation-id: bd99316a-1b8c-41e0-aed7-08d394140608 x-microsoft-exchange-diagnostics: 1; BN3PR03MB1447; 6:RO+ULUAnvfLU87Ge1W/bxN5tTU9FERb9Q8WgAowEPLNgqfoQI+ux+rHbPhNh8XswHax9nnIeEn2r/t1WIL21FUWVCRKZWtP5EsSqQ9iRyjKbV1aGIKZY6lOM2p+cym60uHZEPO57OOzZhsX9Ct1XsxTkEdil/BIdLDv6FkMouq3OubfKyv9wiQxQoW0f3EnbRURjs8Fxy42Tq/t/bUjFXd9tJHOWEuERqZG34MI1UQUbMzQwNffd39AWgn93V/X0N0J7+fhlbHb0p2LAwMRBFmIEDfLxBh5AyCn1+fE6k8sqn30f/6RUoLmbJ1o3yx9O; 5:OtF267bCFHHhPSt2iHXFV9IM9v2+rO0RASSn/Ya6qeNDgRv0gyIhYm7Op8Gt52PNhcafyO341d/s3eR5S/26RdGrwlun0fxxPwRo3gicVUrLzo/XigoI38eGQh8jDHKAS5r6KYZ7pGRp4bzZPEjTOg==; 24:oQdhMZ+qhiATahwL0Fbu7MGkIvVaSKI+UWL94KwB5JRpmze7FuJxuSlpl4KBDgjwC5bGWKV/jMgzji4JflIx+D3fDwXDNZrEx6nSUPUMKZo=; 7:NJlqCYlI641ySZs4gkuQugpm5EJ5JzICC4q8Nu0esi9lQfExKnvsFRLJhpEExNKwtgYghETAZWUzfb+Nr5Qi2GCx9fxdj04n/iiHErmqItWo8i1YtiAyn2yuA/ld2yfUiE/1dz5Cw2AVnDrOVF5BhximAQyLRY89VQZLts+VhH8mqpIVkSQKXHX4RGxmES1ZVdvYCRkcGMDOVkiAqffOgZEuIKrwlALsyIcoTImbEvA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1447; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN3PR03MB1447; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1447; x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(189002)(199003)(5001770100001)(102836003)(6116002)(790700001)(9686002)(7906002)(68736007)(19625215002)(10710500007)(76576001)(86612001)(8676002)(92566002)(122556002)(81156014)(107886002)(189998001)(586003)(81166006)(2906002)(2501003)(3660700001)(2420400007)(5008740100001)(15650500001)(3280700002)(3846002)(7110500001)(8936002)(97736004)(10090500001)(2950100001)(2900100001)(5005710100001)(8990500004)(66066001)(10400500002)(10290500002)(77096005)(19617315012)(19300405004)(15975445007)(5004730100002)(54356999)(76176999)(50986999)(101416001)(5003600100002)(33656002)(74316001)(19609705001)(16236675004)(19580395003)(19580405001)(106116001)(99286002)(106356001)(105586002)(5002640100001)(86362001)(11100500001)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1447; H:BN3PR03MB1445.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB1445AB4EF24CDBFE2323B2CC8C540BN3PR03MB1445namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2016 05:23:30.8899 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1447 Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 05:23:53 -0000 --_000_BN3PR03MB1445AB4EF24CDBFE2323B2CC8C540BN3PR03MB1445namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBwcmVmZXIgb3B0aW9uIDEuDQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206IFRMUyBbbWFp bHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9zZXBoIFNhbG93ZXkNClNl bnQ6IE1vbmRheSwgSnVuZSAxMywgMjAxNiAxMjowMCBQTQ0KVG86IHRsc0BpZXRmLm9yZw0KU3Vi amVjdDogW1RMU10gQ29uc2Vuc3VzIGNhbGwgZm9yIGtleXMgdXNlZCBpbiBoYW5kc2hha2UgYW5k IGRhdGEgbWVzc2FnZXMNCg0KRm9yIGJhY2tncm91bmQgcGxlYXNlIHNlZSBbMV0uDQoNClBsZWFz ZSByZXNwb25kIHRvIHRoaXMgbWVzc2FnZSBpbmRpY2F0aW5nIHdoaWNoIG9mIHRoZSBmb2xsb3dp bmcgb3B0aW9ucyB5b3UgcHJlZmVyIGJ5IE1vbmRheSBKdW5lLCAyMCwgMjAxNg0KDQoxLiBVc2Ug dGhlIHNhbWUga2V5IGZvciBoYW5kc2hha2UgYW5kIGFwcGxpY2F0aW9uIHRyYWZmaWMgKGFzIGlu IHRoZSBjdXJyZW50IGRyYWZ0LTEzKQ0KDQpvcg0KDQoyLiBSZXN0b3JlIGEgcHVibGljIGNvbnRl bnQgdHlwZSBhbmQgZGlmZmVyZW50IGtleXMNCg0KVGhhbmtzLA0KDQpKJlMNCg0KDQpbMV0gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90bHMvY3VycmVudC9tc2cyMDI0MS5o dG1sDQo= --_000_BN3PR03MB1445AB4EF24CDBFE2323B2CC8C540BN3PR03MB1445namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBwcmVmZXIgb3B0aW9uIDEuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9w Pg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5Kb3NlcGggU2Fsb3dleTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1 bmUgMTMsIDIwMTYgMTI6MDAgUE08YnI+DQo8Yj5Ubzo8L2I+IHRsc0BpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBbVExTXSBDb25zZW5zdXMgY2FsbCBmb3Iga2V5cyB1c2VkIGluIGhhbmRz aGFrZSBhbmQgZGF0YSBtZXNzYWdlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+Rm9yIGJhY2tncm91bmQgcGxlYXNlIHNlZSBbMV0uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+UGxlYXNlIHJlc3BvbmQgdG8g dGhpcyBtZXNzYWdlIGluZGljYXRpbmcgd2hpY2ggb2YgdGhlIGZvbGxvd2luZyBvcHRpb25zIHlv dSBwcmVmZXIgYnkgTW9uZGF5IEp1bmUsIDIwLCAyMDE2Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+MS4gVXNlIHRoZSBzYW1lIGtleSBmb3IgaGFu ZHNoYWtlIGFuZCBhcHBsaWNhdGlvbiB0cmFmZmljIChhcyBpbiB0aGUgY3VycmVudCBkcmFmdC0x Myk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5vcjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjIuIFJlc3RvcmUgYSBw dWJsaWMgY29udGVudCB0eXBlIGFuZCBkaWZmZXJlbnQga2V5czwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVw dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5KJmFtcDtTPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41 cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+WzFdJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90bHMvY3VycmVudC9tc2cyMDI0MS5odG1sIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90bHMvY3Vy cmVudC9tc2cyMDI0MS5odG1sPC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_BN3PR03MB1445AB4EF24CDBFE2323B2CC8C540BN3PR03MB1445namp_-- From nobody Tue Jun 14 01:33:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCCF12B032 for ; Tue, 14 Jun 2016 01:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lI7DaQ-Fvk6L for ; Tue, 14 Jun 2016 01:33:16 -0700 (PDT) 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 DDD8512B02C for ; Tue, 14 Jun 2016 01:33:15 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id n184so110470686wmn.1 for ; Tue, 14 Jun 2016 01:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=7K3XEJINbmjdZfKZ/bPsn3QbUG9EABQjxa+Gon2L7yo=; b=KRguAhNcVjN/KZQqUMjqUF4rdCxKgrglmyFPJdVUWtEsdTxU4X4S8tR9NL5i7aXhjj jeXwEIzo6QNQlfx26vQ+e4a1gNd2Z7/KYoYfpLGz8hP9gE4DZ1FzWxEcNrQrcvJfp1de t04580fkXUmtd9mEkWWKuVSGbMiMT8vldY/bDiqoX++mCKzXhKslnUm8R0mgmMPU7PrM UTafORQ0u2YqUn+7Q8OF1PL1NTqnQPGZfyxQ146v4E6l36mLlo4QPRuYE7pyI/9jFg6p 0drREJGPYSp3taQZVNnUUiO77BqpFMc7fxVXRZHy5pS0L5Nldjv1qh6M6wQmHcsRrh6i 02Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=7K3XEJINbmjdZfKZ/bPsn3QbUG9EABQjxa+Gon2L7yo=; b=e7asCQQrcmkcMrIiSJ2JnG9XWmAc4wBWJIFFhiJ4En5ldHDuObqjJxCIMMkXs4K+qa FYMoOTykkUGJ1ZuDIMLpkLx0WnqbQrQI/diRfd+zuUOM/E9/XJmBj7zuxoEuRYzOBpK0 +ybDvQ8ZuIFr/04cZOFK+GxqKBnZAhe+AQmcVcHH66ai18yGJPf0IAECIaZT7KRFGnyg bQMR+0hVhIt8bZ6lUxR1MmhmdcEIuAATzffLY3wgpYDR+FyRdB+qv7Dt4LBJuULfPIIV fR8Bd4870W7/RE70fO74KDbUdRO4f/NAJRWtGaFdWAkKZqDMrX5bGkMLt+j4pepi+e2C oOwg== X-Gm-Message-State: ALyK8tKYck+O6zS7jZg4Q5ynMov+rgqnMm6S9Dw8QWSRHK+kfZJzNHtoNzm63ybF3YfoDA== X-Received: by 10.28.44.87 with SMTP id s84mr4892666wms.61.1465893194408; Tue, 14 Jun 2016 01:33:14 -0700 (PDT) Received: from [172.24.248.248] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id r16sm2846168wmb.23.2016.06.14.01.33.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 14 Jun 2016 01:33:13 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7F1868A1-DA39-4C7B-857C-7007E8EC3797" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Tue, 14 Jun 2016 11:33:11 +0300 Message-Id: <95ACB42E-A0FF-4E46-87E9-212DAF033F42@gmail.com> References: To: Joseph Salowey X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 08:33:20 -0000 --Apple-Mail=_7F1868A1-DA39-4C7B-857C-7007E8EC3797 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 13 Jun 2016, at 10:00 PM, Joseph Salowey wrote: >=20 > For background please see [1]. >=20 > Please respond to this message indicating which of the following = options you prefer by Monday June, 20, 2016=20 >=20 > 1. Use the same key for handshake and application traffic (as in the = current draft-13) >=20 > or >=20 > 2. Restore a public content type and different keys >=20 > Thanks, >=20 > J&S (1) One important (for me) use case for handshake messages after the = original handshake is client certificate authentication. Disclosing that = the user has just touched the magic resource that causes certificate = authentication reveals actual information about what the user is doing. = I haven=E2=80=99t seen an argument about why using the same key is = similarly harmful. Yoav --Apple-Mail=_7F1868A1-DA39-4C7B-857C-7007E8EC3797 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 13 Jun 2016, at 10:00 PM, Joseph Salowey <joe@salowey.net> = wrote:

For background please see = [1].

Please respond to this message indicating which = of the following options you prefer by Monday June, 20, = 2016 

1. Use = the same key for handshake and application traffic (as in the current = draft-13)

or

2. Restore a public content type and = different keys

Thanks,

J&S

(1)

One = important (for me) use case for handshake messages after the original = handshake is client certificate authentication. Disclosing that the user = has just touched the magic resource that causes certificate = authentication reveals actual information about what the user is doing. = I haven=E2=80=99t seen an argument about why using the same key is = similarly harmful.

Yoav


= --Apple-Mail=_7F1868A1-DA39-4C7B-857C-7007E8EC3797-- From nobody Tue Jun 14 01:37:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6FD12D0B7 for ; Tue, 14 Jun 2016 01:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7hMQCuPc9Pw for ; Tue, 14 Jun 2016 01:37:11 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d: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 4BA7512B02C for ; Tue, 14 Jun 2016 01:37:11 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id s186so84021779qkc.1 for ; Tue, 14 Jun 2016 01:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WXSyW7jx9YqUMG9z1z/Ur7rMTXrYy7W3/r0KJ2tZEwc=; b=GzVJ1ojKwoJksMSKK6zVbxFubCgubW7iuJuPgG2uyF+egySf8YhG3k8PNUaTOjx0iq +5BERVfXnBgi06SD+uR21SytctY+OpEf5ABmbShggBo6D/rXMBLXqBphnO5NAUx2f+54 qbECmUOsmLJSVonmBsAu/W5L1LH8U9rIa5UMpSOUeClY7lWP2MvQfWIc35p+uk+XOg6C 01SzRGEICoQD9LXa4L62hC1lARt/0lJcKnI/VbPYR0Bi6CulbVcQTjFcaiIYDnqP5FxV ln3n1YPzKfWa/U4MEEdH1YDqHFNNlJpj/Pys2/c8SEGpc5VHaFyIcx/K61smKOeSGLhw +6EA== 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; bh=WXSyW7jx9YqUMG9z1z/Ur7rMTXrYy7W3/r0KJ2tZEwc=; b=JWtnL0QwHCjHydBDNMiIfuVYN8H8NRrHnczPFxMxi77v5HeBPkOXImrOFdGPXYZZyP sAMUyb+RDY0O6NQpDp1edtJKdhgjhgeXmHDKxMMZa9lQqVJPgZYRyvu6VK10pPr+B3VJ 21rb+8xRs7bOB8sKuPlU1WS71fv7OVHa9HBB8GjRYO+woydsbS0sm7vP+GuxWrX4z6Dt Kjc6koxAK6cRmNdDm4B87lxHXJXlo6lRK47p+Z73yP41fFaPzKOyQtBnKt/dblHVm18M asrNWivA7fEqbA/eytCaG04uHbTM6Vb5oOgD1L7NLYfizq4dJ7nbe1nWfK5sGUyfnALd HgFQ== X-Gm-Message-State: ALyK8tJyu267Y7Z1FbO2PklS4OjKNZCwziCde6uJecJQKfrs3KdcbA6VRmw5GPTwFovh3Qm3Qd3anJS9cLgLJA== X-Received: by 10.55.78.16 with SMTP id c16mr7404332qkb.48.1465893430384; Tue, 14 Jun 2016 01:37:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.37 with HTTP; Tue, 14 Jun 2016 01:37:09 -0700 (PDT) In-Reply-To: <8760tc3kd0.fsf@alice.fifthhorseman.net> References: <8760tc3kd0.fsf@alice.fifthhorseman.net> From: Martin Thomson Date: Tue, 14 Jun 2016 09:37:09 +0100 Message-ID: To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 08:37:12 -0000 On 13 June 2016 at 21:27, Daniel Kahn Gillmor wrote: > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: >> 1. Use the same key for handshake and application traffic (as in the >> current draft-13) >> > > or >> >> 2. Restore a public content type and different keys > > Given this choice, i prefer (1). +1 However... I confess that I still haven't properly internalized the objection from the cryptographers, and that means that I could probably live with a public content type if more convincing evidence for the value of 2 could be produced. From nobody Tue Jun 14 02:04:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07C812D135 for ; Tue, 14 Jun 2016 02:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuaDbQWzcahZ for ; Tue, 14 Jun 2016 02:04:32 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 93CCF12D12F for ; Tue, 14 Jun 2016 02:04:32 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id t190so55500101pfb.3 for ; Tue, 14 Jun 2016 02:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=xrQwMCl8p6PTXVWwTQtQoo55dljWDwG+eP5PbZxUKYE=; b=ZXUtpEXWawft6BPbkheijCQikeywAzuLA36260MO9iujoBDyPQvOFEGVA+zlDilY+Z zJ0Aj6QJdi/Sqivfb+yPpZKrI17707pu+Aua8+/0RhKyVYVk6uelVHOurEXaER/YCkqM ZvmJG/jhRpHMxWTvmfxKQEdYxqf/yJKbPBQuA= 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:from:in-reply-to:date:cc :message-id:references:to; bh=xrQwMCl8p6PTXVWwTQtQoo55dljWDwG+eP5PbZxUKYE=; b=FmE7Bzp/VBSc40HufgLEkHRvWM7Wq9H7af+Bipf+i2GI7yqWusi1+whym2X9Y1r6ut T4GLAYaLLJD7oMdIzI/QzaNuLnY8WlqVrHWFJRIi31dwuZNZTr+xlzvJpRAKSHCTmWRD eM4PnPFAxt5yS5tvg0lgcXG12fn3Mc3X4gu0GxPBUBiuqfQc7sc7N44ASJ/X8AzTWxOe 5tD/ve0jN7FDPrURHjtDUV0uVl2s250E0644Mc9B/TJp6bvBvcyfoQBjYP/OugApwgNK Uk9oxfzY8J2s31DEXIn8prPZHmqOTKRTDpFmdex2Htb0cP4Ca7eb7zyCOsPvMgNA80nZ 4csw== X-Gm-Message-State: ALyK8tKA9G5BZBZYlLNMQhRwH82FOz5pspda05CRydAGOWldab8j9LbVzT7y+SUfa3ygPg== X-Received: by 10.98.46.70 with SMTP id u67mr2552836pfu.134.1465895071184; Tue, 14 Jun 2016 02:04:31 -0700 (PDT) Received: from [192.168.1.234] ([114.121.233.60]) by smtp.gmail.com with ESMTPSA id ym9sm13888403pac.25.2016.06.14.02.04.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 14 Jun 2016 02:04:29 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_92E49AB3-04BF-4B63-B2CB-EC2D4575F2A9"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Aaron Zauner In-Reply-To: <96CBAD0F-0F0A-4095-81FD-09EE804EB7F6@azet.org> Date: Tue, 14 Jun 2016 17:04:22 +0800 Message-Id: <1367F829-067E-4449-AB53-5357945BA9B1@azet.org> References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C817BE@uxcn10-5.UoA.auckland.ac.nz> <54302B87-4730-4B8E-9F55-B33B89425A51@azet.org> <53384A13-5F80-4CF0-BD8F-F68E304ADF15@azet.org> <3B2C6D5A-939E-4539-B902-D4502EB9739C@azet.org> <96CBAD0F-0F0A-4095-81FD-09EE804EB7F6@azet.org> To: "tls@ietf.org" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: RFC Errata System Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 09:04:34 -0000 --Apple-Mail=_92E49AB3-04BF-4B63-B2CB-EC2D4575F2A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, It's been a few weeks. We by now know of at least one other affected = vendor. I think this errata is valid and should be accepted. I'll take = any feedback and improvements if valid. Aaron --Apple-Mail=_92E49AB3-04BF-4B63-B2CB-EC2D4575F2A9 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----- iQIcBAEBCgAGBQJXX8iXAAoJEOTbZJL9ubXVqNIQANxjKEn7EQJwSCR3dtQwbSGR lVQCQSwObMvgoMfD/daoCaTbM997fyhVvn/dWC8Gb5PKhKWMllhGmwcLlb3XrIRz SUg3dzQgoEcxkcSYudm98ux4/f/1cArkf3AMGY4g6L5gk0zuFO45m1/dPKAKOPqA UbYNfLHagd9PnGZC75bTOcSbFmfhkX1wtViqSe6shLXIV+bRjcikF42I0AA7CCec /VhgCqmHSrxPufeq+Yb2fAUVjHLKebhVkfO4qS+QprPxTRpmlHMt8k/lC41lJdaG THgz+FTmFHjNrgVvoOLzlXR5/GtaIvIRxiZ0GmAY7vSKTk+6ZdMGLkAbl2Nu/h8t YGr/6irNuzY0MjBcBpP5ABbuS2T7OTfDRU1vdjqTLr4fo8gnehfkhJ+KPwIXcmXA pDrB8WmOI0u/mR/WNeOEBNmrN9Eu2V5GI+rg1wBvUXofyLkLhjm1njICEvT7sHjf dKmTCmZyV8s17ugN9E/ofux8gmKWV95KuGUus9cxhS/rwjA4dPv6/3I1FHebR1Rf +sJTwxXHMy6O3ituhSUYTVQMBDUn5/QSKlSSjjYNxtBivSQSEwp9/yWI3zwhanPd c7TCTCGPX+kuVkhZiVrikzj6fBIBnFUWJ+DmfMcuZA+toIz38RelzzrwJ3XS8WlN JaYqBa1Ik5N77z42CZk4 =pkpD -----END PGP SIGNATURE----- --Apple-Mail=_92E49AB3-04BF-4B63-B2CB-EC2D4575F2A9-- From nobody Tue Jun 14 02:18:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAD012D11F for ; Tue, 14 Jun 2016 02:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eng.ucsd.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsZie2BOAXi2 for ; Tue, 14 Jun 2016 02:18:18 -0700 (PDT) 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 5A75C12B032 for ; Tue, 14 Jun 2016 02:18:18 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id k204so113506208wmk.0 for ; Tue, 14 Jun 2016 02:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eng.ucsd.edu; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=J/r1Hqee2Cv4ZqNrfcYKzsGows9UFd/aZEDAqfqBKpc=; b=QqI2XVyWBTHS6cysF2sdXkoWZrFRmIcMS3UaXjcEqBBwal2LKip5I+vwZCpiGwFoIT 4ATUnqVxEqJ8mVJxD4uH6T0g5RXCLCE44odDSxML4qzJJz02IpH+tbjrXqzHKumOcp7N bfyevuPrzBhvQFAq5Yr1ADlWfo2WKaZn99JPI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=J/r1Hqee2Cv4ZqNrfcYKzsGows9UFd/aZEDAqfqBKpc=; b=hrSaAsT4J/YwU3o91rn5TJpt2MB44LbwK4SE+8ZHq+h0jyquPOFlVbbD1hbvn8yHgN FC6NNGbQk9orRtVXIQW66Uu4Iw90bn15ak1kYVqCm3j8zGEfA4xzVo/FJShA6ZP1J+Iz KRgKWCqdy9RkAps6PvOjVFhQGu5tG5/jxp7Mi7nDcBUxiz0Aem5FBOjTK42ynPjXrpIK kPkwfTMNCd98GQ11ReTvSEeRAcahfiK3HwEnEbuaMMJEY3rf/b9QG+2lyiFqUCYd5Jtd wD++BObC4rf4im2qP3REnOqNlpsCU+lHMtiETQdQea1AfvIld35LeG5Rm4AseheVG3AS qsSg== X-Gm-Message-State: ALyK8tJPGDY16w7miVGK4r7SMNkXGNrnQQrx3JtnIzWrzgYsaBK+tNs5NrtGPTEtobjgsY39 X-Received: by 10.28.69.210 with SMTP id l79mr1551596wmi.31.1465895896483; Tue, 14 Jun 2016 02:18:16 -0700 (PDT) Received: from [10.71.48.202] ([185.25.95.132]) by smtp.gmail.com with ESMTPSA id 124sm3086401wml.12.2016.06.14.02.18.15 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 14 Jun 2016 02:18:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Bj=C3=B6rn_Tackmann?= In-Reply-To: <87d1nqc9gq.fsf@alice.fifthhorseman.net> Date: Tue, 14 Jun 2016 11:18:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <38042862-8DF3-48A1-9B35-2D902EE12FC1@eng.ucsd.edu> References: <87d1nqc9gq.fsf@alice.fifthhorseman.net> To: "tls@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Closing on keys used for handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 09:18:20 -0000 Hi dkg, sorry for my late response. Let me start by saying that I do not believe that this is really = critical; after all, we can prove alternative (1) as well =E2=80=94 = it=E2=80=99s just less clean and makes the proofs harder to write, read, = and verify, which is generally not a good thing for a cryptographic = protocol. On the other hand, the privacy improvements offered by = alternative (2) appear to be rather moderate; even if we were to = realistically achieve the best privacy it could offer, it would protect = the fact that a =E2=80=9Cnew session ticket=E2=80=9D message (is this a = gain at all?) or a client auth message was sent. If I understood = correctly, client auth has not been widely used in previous TLS = versions, and even if this would change, it=E2=80=99s not quite clear = how big the gain is. Maybe you have more precise insights into this than = I do? > On Jun 9, 2016, at 11:56 PM, Daniel Kahn Gillmor = wrote: >=20 > I confess i was hoping that double-encrypting would provide some = measure > of useful key separation for cryptanalysis. I don't think i = understand > Ilari's explanation in this thread, though, so i'd appreciate any = other > attempts to clarify. Double encryption is not problematic. It just does not have advantages = over alternative (1) in terms of cryptographic analysis (it does not = quite help in modularizing the proofs). On the other hand, we=E2=80=99ve = heard (others may want to chime in) that it /does/ make the = implementation more cumbersome, in the sense that it requires more = changes to the existing code base. In that sense, it appears to be strictly dominated by alternative (1). >> PUBLIC CONTENT TYPES >>=20 >> Clearly, having a public content type and separate keys for handshake = and >> application data provides full key separation, at the cost of = revealing >> whether a given record is handshake or application data (and = potentially >> alerts). The major question that the group had was whether it was = actually >> possible to conceal this information effectively, even with encrypted >> content types, since hiding the handshake messages in the application >> traffic requires detailed knowledge about the application traffic = pattern >> (e.g., packet lengths, timing, response patterns, etc.). It=E2=80=99s = clear some >> analysis of this is needed. >=20 > We know that traffic analysis is difficult, and may in some cases be > impossible. This is an area in need of active research. However, > deciding to make it *always* impossible to protect because we don't = know > how to protect it absolutely is "security nihilism", and i hoped we = were > moving beyond that mindset as a community. I beg to disagree here. First, we would not drop it for no reason whatsoever. We would drop it = because dropping it has other advantages. It=E2=80=99s a trade-off. Second, we should in any case carefully point out that this mechanism = alone, i.e., without proper padding etc., may not provide any additional = privacy guarantees. A security mechanism that does not work can be worse = than no mechanism at all if people start relying on it without = understanding what it achieves. Introducing a mechanism without analyzing it is somewhat akin to what = happened to encryption with compression. (Used properly, it can be = useful.) I hoped we were moving beyond that mindset =E2=80=94 sorry for = echoing ;-) > If we don't have a mechanism to hide this metadata, then we certainly > won't develop any useful practice around actually making it > indistinguishable. Protecting users is a multidimensional problem. = We > should provide a mechanism to make this information indistinguishable = in > the axis we know how to handle (encrypting the material itself) so = that > there is a reason for people to work on the axes we don't yet know how > to handle (protecting against traffic analysis). I=E2=80=99m totally in for protecting user privacy. I simply believe = that we should first specify what we want, then see whether we can = achieve it, and then build the mechanism that does it. Cheers, Bjoern -- Bj=C3=B6rn Tackmann Postdoctoral Research Scholar Computer Science & Engineering, UC San Diego From nobody Tue Jun 14 02:23:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6214412D0E3 for ; Tue, 14 Jun 2016 02:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eng.ucsd.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6TUXBQLAyWb for ; Tue, 14 Jun 2016 02:23:02 -0700 (PDT) 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 9528412D0C7 for ; Tue, 14 Jun 2016 02:23:02 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id v199so111953043wmv.0 for ; Tue, 14 Jun 2016 02:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eng.ucsd.edu; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=Gp6bjY7PcXnuGP4GLkBK3vIPqrVpp7kBM2eTcm4QpC0=; b=T26A5wbQcwhUQ3xVNAAjAJo+VC8A/+YbbjfILgXYL82qJyRIbCSN+1fV0KDb2MlDps 2UsR54TSoSTrDEy1KFKWCo4d+Rgp8So313yZcJ6dT2KULn/bamYYd/GpKQp/1JjG5WGB obSW50HObkrj1MFPk9B+W3kw0ZkHOlSBMQJi0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=Gp6bjY7PcXnuGP4GLkBK3vIPqrVpp7kBM2eTcm4QpC0=; b=G7E7C2wgOk6e6wova2S+Vc45SANKBMY5QxAYOPfkGv+Zkvyas+hal1uigDqQr1UAAq vd5Q1YOV6GF5H+QBnOCVF5FFdYNw0wzhqfpg+9LV5gDZxjiC7oachnmTe/Nhea1VRT8X qaeD/uTWjWUXYjiW11d3TjZY0s9Zofayu2s4qVOHtRYxVQTB1y5h2uPjj6MJ1VeGRvVS FSZtZsXh9Uo6dWYihvHMe6ulc4X+bbpFN3fSumYljBJ6hXeBH64xe+TZdNtW4aaVsOBp s+AD7EUG68KwsbvpQud9sfUe4KmzWaujvNXdDGkWal4EiGm+aDUhcvYvaCQliAAZ9BOm F2bg== X-Gm-Message-State: ALyK8tLL6DYG+MlePcS2jkmDWTmnvN+Sw9jpkRrRFCiqeBQv5vdOqEToNzxAmblSZKA+yRcp X-Received: by 10.194.2.44 with SMTP id 12mr5026886wjr.61.1465896180967; Tue, 14 Jun 2016 02:23:00 -0700 (PDT) Received: from [10.71.48.202] ([185.25.95.132]) by smtp.gmail.com with ESMTPSA id o203sm3066799wmg.22.2016.06.14.02.23.00 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 14 Jun 2016 02:23:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Bj=C3=B6rn_Tackmann?= In-Reply-To: <3B833484-DFD8-419A-877C-C1F259AC4528@gmail.com> Date: Tue, 14 Jun 2016 11:22:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <889AAA52-C47B-42C5-887F-B9C5D685CE3F@eng.ucsd.edu> References: <8760tc3kd0.fsf@alice.fifthhorseman.net> <3B833484-DFD8-419A-877C-C1F259AC4528@gmail.com> To: tls@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 09:23:04 -0000 +1 > On Jun 14, 2016, at 7:08 AM, Karthikeyan Bhargavan = wrote: >=20 > I prefer (2) >=20 >> On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor = wrote: >>=20 >> On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: >>> 1. Use the same key for handshake and application traffic (as in the >>> current draft-13) >>>=20 >>> or >>>=20 >>> 2. Restore a public content type and different keys >>=20 >> Given this choice, i prefer (1). >>=20 >> --dkg >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jun 14 03:23:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE6912D143 for ; Tue, 14 Jun 2016 03:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.348 X-Spam-Level: X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IL93Eeu5ndZ1 for ; Tue, 14 Jun 2016 03:23:19 -0700 (PDT) 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 F369512D097 for ; Tue, 14 Jun 2016 03:23:18 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D536C7D0FD; Tue, 14 Jun 2016 10:23:16 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5EANFJJ019092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jun 2016 06:23:16 -0400 From: Hubert Kario To: Peter Gutmann Date: Tue, 14 Jun 2016 12:23:05 +0200 Message-ID: <1843800.YErRuY4C85@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.12-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CA0C94@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C9CA49@uxcn10-5.UoA.auckland.ac.nz> <22902566.AuEvmjhU12@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4CA0C94@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5844766.OFXazMUsBD"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 14 Jun 2016 10:23:18 +0000 (UTC) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Adoption of TLS-LTS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 10:23:21 -0000 --nextPart5844766.OFXazMUsBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 13 June 2016 19:51:42 Peter Gutmann wrote: > Hubert Kario writes: > >to be pedantic, the RFC describes itself "a profile" while in realit= y > >it modifies the protocol in a way that will make it incompatible > >with "vanilla" TLS 1.2 implementations > > >=20 > Oh, right. Well that's easily fixed, I used "profile" because I > couldn't think of a better term, the best I could come up with is > "plan", but it's not really a plan either. If people think "plan" is= > better than "profile", and it deals with Russ' objection, I'll change= > it to that. Alternatively, if you can think of a better term than > "plan", let me know (or forever hold your peace > :-). "TLS refitting for Long Term Support" "Adaptation of TLS for Long Term Support" "LTS revision of TLS" "LTS addendum to TLS 1.2" (amendment?) If "revision" does not overload the word too much in this context, it's= =20 the one I would vote for. =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 --nextPart5844766.OFXazMUsBD 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 iQIcBAABCgAGBQJXX9sJAAoJEJKo0bgB0vX1kMMP/3Kd2n7j8fAJyX2WqTojtT9g 18jyTdbMSUUwpQ6h9L4tQt9oF5Ge5zOPlEkvnt0R7p6D4qA9zEo0jniAS3VzEiMh RMdzIJ51bALKIGh257GaYQZYt/y7y4bM0GnmRpOvL2zYZ8nvh75Y1OCDAm20dnHg FEijLOqqY1/xiWbr2BTJi4zr97ukRD6DKsc7ia+K2wgcVVv8GMp/VQhDhDro52sz fxavGer+Ltn9zCiA0iF7KXcBOFkEQew6WLP8OOYMNuTPMxPExYBrLXbmXZ84RHZA B53bWp8O+Gkch8/J70Kq0s+kT8tL8COYUkDYglZvzUwz6B2FQJ3HgcrOqYqP312U knXjUbZz1GGyUTJTTZfkVKVIDIBN9EeaQ5cpj+7f+coSLM88R/ROpmh5TZyIBAJi alxqgIo76APdDXFg4e2xJaFI7kZXVGcCtNZdB3l+7RuoNXZJgKubmlbhZasbhyeP X8qTBjrDMMQ3x85LmsQUrjJjWQSS2vdJHEA23B6UR1fniTYl7w41zkDDtb7gfbfi eY17O/5HRhr/TRqFDoW3cCdhIBJXazwaY32XTUarjvpp8GMLauf9u4gK41E3von1 uKGTWYPXotcFPBZ49W3ORPhVlrzpC4uUUt61KepYSoHxVqZ+KtMfMnSWi3Bzq5if mE/7TTv8i2UDIqVr9Oti =HfTq -----END PGP SIGNATURE----- --nextPart5844766.OFXazMUsBD-- From nobody Tue Jun 14 04:22:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1436512DB7A for ; Tue, 14 Jun 2016 04:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjRhuDmL4sV8 for ; Tue, 14 Jun 2016 04:22:44 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c: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 6B1791200A0 for ; Tue, 14 Jun 2016 04:22:44 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id d185so92431893vkg.0 for ; Tue, 14 Jun 2016 04:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=T0OX8uKrdcCywIvKYJxhNxhTC8Ntg3eZnkP0HDfCf/M=; b=BsK8gw7IzsffRCKWFWCUHUlWInUU4A+Jm8utLq0YsyVJSJaah+sp5WCf46BNRVNoUj yLaXpSBnOlkT70t+B5IhKCyIvLjuGiPFeDIPOnANeG1OR1iWthFtBCYpBVLFZETenuOk FGBh9ur8RP4g2Pgs3xugnXdC7G8r5GgVASXMDce4pjdYBfDVuslO/jDEuxwcxM9vzZEt SKvDmG23Gin3C88Ph/+xWxDkFXQ1EJ/Kr9bMdMI7ZtVLQotb2kt4Jgdk/9VuOznssVfp hj5aMOd55jZe43FE7YZbiK1bHLJLMG3KUSkC7oBEqfGCYFLULeF2+WbxTSyEbXZsQo3S HK9w== 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; bh=T0OX8uKrdcCywIvKYJxhNxhTC8Ntg3eZnkP0HDfCf/M=; b=RCG/zKSpjN+mxI3hq8iKRZrXYgEfK04hfJOhadiNc+xS0ySR8ynQXGIQXO1HhWO2CB v50+EAx7SGi9gojdM02aKTFUv4qhGf+q+/Dqokc6t+N6mdYmsy29yHHZ+5LUwlNBa1k0 YVu4mF8MBGxUgCNyzL3eE7N6VZmXpGBIu99lLRLbejD7tKXYf9hfkAoxwBCUZizzOK1c MCLxt1m/zr/pB4MJHCL3/lQKXVeICnK/lZNfdKf+JM77ic4Gc0rZn2/Vf5maaI7gH2b8 PfcxL6XrzxXdkHl5DU8zYPhIMzzIaZLuctN754f5arLcYsEhIYd9Xrar0leBbl+VetvD Y/Ag== X-Gm-Message-State: ALyK8tKiNcUeiASPdlrPegRN1N7MtzLdmTIPLUdKA1BMyNroDYDhOJ2k7xnETfKp5urECnziHzGRY95YtmsZ3Q== MIME-Version: 1.0 X-Received: by 10.31.167.84 with SMTP id q81mr8933638vke.51.1465903363346; Tue, 14 Jun 2016 04:22:43 -0700 (PDT) Received: by 10.159.35.78 with HTTP; Tue, 14 Jun 2016 04:22:42 -0700 (PDT) Received: by 10.159.35.78 with HTTP; Tue, 14 Jun 2016 04:22:42 -0700 (PDT) In-Reply-To: <3B833484-DFD8-419A-877C-C1F259AC4528@gmail.com> References: <8760tc3kd0.fsf@alice.fifthhorseman.net> <3B833484-DFD8-419A-877C-C1F259AC4528@gmail.com> Date: Tue, 14 Jun 2016 12:22:42 +0100 Message-ID: From: Watson Ladd To: Karthikeyan Bhargavan Content-Type: multipart/alternative; boundary=001a11415d603f5f7505353b39d0 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 11:22:46 -0000 --001a11415d603f5f7505353b39d0 Content-Type: text/plain; charset=UTF-8 On Jun 13, 2016 10:08 PM, "Karthikeyan Bhargavan" < karthik.bhargavan@gmail.com> wrote: > > I prefer (2) Same. It's clear 1 makes proofs more complicated, making mistakes easier to miss. > > > On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor wrote: > > > > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: > >> 1. Use the same key for handshake and application traffic (as in the > >> current draft-13) > >> > >> or > >> > >> 2. Restore a public content type and different keys > > > > Given this choice, i prefer (1). > > > > --dkg > > > > _______________________________________________ > > 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 --001a11415d603f5f7505353b39d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 13, 2016 10:08 PM, "Karthikeyan Bhargavan" <karthik.bhargavan@gmail.com> wro= te:
>
> I prefer (2)

Same. It's clear 1 makes proofs more complicated, making= mistakes easier to miss.

>
> > On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> >
> > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:
> >> 1. Use the same key for handshake and application traffic (as= in the
> >> current draft-13)
> >>
> >> or
> >>
> >> 2. Restore a public content type and different keys
> >
> > Given this choice, i prefer (1).
> >
> >=C2=A0 =C2=A0 =C2=A0 --dkg
> >
> > _______________________________________________
> > 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

--001a11415d603f5f7505353b39d0-- From nobody Tue Jun 14 04:25:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290EC12DB83 for ; Tue, 14 Jun 2016 04:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org Received: 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-uBmMxAmDD7 for ; Tue, 14 Jun 2016 04:25:43 -0700 (PDT) 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 4F36912DB85 for ; Tue, 14 Jun 2016 04:25:43 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id t129so88807851vka.1 for ; Tue, 14 Jun 2016 04:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IuxBk/w6JomB+S1TjrOwAVt6NQUqqfudfyZFsqLx2LI=; b=oPISW5PBVuJ1ZmWIS7X1M2AdH/NZp7iB7oCLsOPX2nllVeMvimKQwgDUmjYvcwfuk5 cJv1tDCGUrbi4Sn/6ScQPCFe/tGrgDQvTXxtfr3DQVxNaOtmHEhWiximK9nDYIKoI2RN h1evrhAq1NX71KmO4M15qXahI+/GCt7vF2PUE= 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; bh=IuxBk/w6JomB+S1TjrOwAVt6NQUqqfudfyZFsqLx2LI=; b=RJbQmCVh8YwYq1cl8KTvuU8Rwgy3MdWV8CGc3JQAf/G0AapUqkCgsW1+Y0Qr+s4478 n6VGSwjoAa9IGH3CEzgzoIStaS7CVJQ/ZV4eQMeSS6Z/46mMMgR/tvrHq8r4mqZpkcan +AoWUtonxG90pI8ek5IhzDYwHg611MzCbhX63w7G6EmKxPnKV2P4wJYvgVa4+m3EtG5A f4v1Zlr4ht4SO7k7m5o2zMPzojvsNZQAwHTAnlO6n0PV46oD12PtZos1K0x0TqiwN9pj hK3JnRoA5D4pW7a8v2VVLOsbI60L0Hdw0KEdU13A+tn2eDCL/6AW1Ehj4Hp06PMYv2b4 n9dg== X-Gm-Message-State: ALyK8tLQVU56OxjHGui6ipeKKoqoBZJonPrCtw672EX1Qh6VUyGau5ZztPgo9GVGrESx5JsCsJ/cbGR3Jp41DBwW X-Received: by 10.31.61.196 with SMTP id k187mr8603041vka.43.1465903542366; Tue, 14 Jun 2016 04:25:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.27.195 with HTTP; Tue, 14 Jun 2016 04:25:22 -0700 (PDT) In-Reply-To: <1367F829-067E-4449-AB53-5357945BA9B1@azet.org> References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C817BE@uxcn10-5.UoA.auckland.ac.nz> <54302B87-4730-4B8E-9F55-B33B89425A51@azet.org> <53384A13-5F80-4CF0-BD8F-F68E304ADF15@azet.org> <3B2C6D5A-939E-4539-B902-D4502EB9739C@azet.org> <96CBAD0F-0F0A-4095-81FD-09EE804EB7F6@azet.org> <1367F829-067E-4449-AB53-5357945BA9B1@azet.org> From: Joseph Lorenzo Hall Date: Tue, 14 Jun 2016 07:25:22 -0400 Message-ID: To: Aaron Zauner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" , RFC Errata System Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 11:25:46 -0000 s/it's/its/ in one place in your errata text, Aaron. On Tue, Jun 14, 2016 at 5:04 AM, Aaron Zauner wrote: > Hi, > > It's been a few weeks. We by now know of at least one other affected vendor. I think this errata is valid and should be accepted. I'll take any feedback and improvements if valid. > > Aaron > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 From nobody Tue Jun 14 04:27:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5A612B01E for ; Tue, 14 Jun 2016 04:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.625 X-Spam-Level: X-Spam-Status: No, score=-5.625 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2IY1hKp93S1 for ; Tue, 14 Jun 2016 04:27:20 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id B8CF212D512 for ; Tue, 14 Jun 2016 04:18:22 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u5EBG1Wt046055 for ; Tue, 14 Jun 2016 07:16:01 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "tls@ietf.org" Thread-Topic: [TLS] Consensus call for keys used in handshake and data messages Thread-Index: AdHGLnRIoKzTaTZs8E28LhLUaw3ZYw== Date: Tue, 14 Jun 2016 11:18:19 +0000 Message-ID: <20160614111828.18296913.41202.73993@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="===============0735903836==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-14_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606140125 Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 11:27:21 -0000 --===============0735903836== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Key reuse often ends up causing problems. IMHO a more sound approach is (2)= . IMHO it isn't prohibitively expensive either. Sent=A0from=A0my=A0BlackBerry=A010=A0smartphone=A0on=A0the Verizon=A0Wirele= ss=A04G=A0LTE=A0network. =A0 Original Message =A0 From: Bj=F6rn Tackmann Sent: Tuesday, June 14, 2016 05:23 To: tls@ietf.org Subject: Re: [TLS] Consensus call for keys used in handshake and data messa= ges +1 > On Jun 14, 2016, at 7:08 AM, Karthikeyan Bhargavan wrote: >=20 > I prefer (2) >=20 >> On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor wr= ote: >>=20 >> On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: >>> 1. Use the same key for handshake and application traffic (as in the >>> current draft-13) >>>=20 >>> or >>>=20 >>> 2. Restore a public content type and different keys >>=20 >> Given this choice, i prefer (1). >>=20 >> --dkg >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --===============0735903836== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKMz1Y1wAAAABunjANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE2MDExNDE3MzU1MloXDTE5MDExMzE3MzU1MlowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCz HVEw2ojNZjWEnTASyJaQIvzziBmrH07FzMEY2xFGNDJpss38CcFRjfRx1EyEp7BrFdAXC2pHjFwa gFr+McYdXZiKEci0Mzna2uibsMDVbhlT6TwtmAL6QzdtjN28dn+7vQUkRUWUm9VVaBVVxUgX3f2l oEZsJNvWb7C8vj2DZF/uEt/EU/9KcUuodMgCR4zYLFVpNh1U6tCYACNDNtj/nmNjubtez1Y56zjZ AVOXZWsjNCPrC2jVwDdg1AIcs5ayDMOC2p1F95kSxWsJwinKfSe8p2/YR/cwUo8ljFoBPj60AGW3 WjaJyKXK+ZgJwjwl9gG/pg2T4mQhIAIZWZQ9AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUtKJz3aEd G/MvxjE38EW6PHdcUDQwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAJTu0/WcX0ebe9UfUMslvy9fC2aCQong cVcEKlEjU8IvCKa6YpZHQKTVXQ3e4KKvw1DgzFvq8/rOv87Woj45q8smgNyivgAMCnrT7a6B/9Kn 85l9BjeoLMPLypvsmz1l7oX45NPr3LF4VEMzxqczdovS14woPKdegEKQYyPSZGhKTCCe/9FhtgEc 3gfVyE1mH6ZNeDEalr7nx7F0qemhh3QN6i6XPrudzv9el5JeovPedZ0JqDT0ctXj6ECYOiEyEfJm 85C5QGmpjLmCM99gAmgpP5Tx6APB/tvcUw/mgt4HOvqavGkvUkoJ8XEEwt9AgXaznS626Kb8RpAh w2zN2yMwggTqMIID0qADAgECAgozPVjXAAAAAG6eMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTYwMTE0MTczNTUyWhcNMTkwMTEzMTczNTUyWjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALMdUTDaiM1mNYSdMBLIlpAi/POIGasfTsXMwRjbEUY0MmmyzfwJwVGN9HHUTISnsGsV 0BcLakeMXBqAWv4xxh1dmIoRyLQzOdra6JuwwNVuGVPpPC2YAvpDN22M3bx2f7u9BSRFRZSb1VVo FVXFSBfd/aWgRmwk29ZvsLy+PYNkX+4S38RT/0pxS6h0yAJHjNgsVWk2HVTq0JgAI0M22P+eY2O5 u17PVjnrONkBU5dlayM0I+sLaNXAN2DUAhyzlrIMw4LanUX3mRLFawnCKcp9J7ynb9hH9zBSjyWM WgE+PrQAZbdaNonIpcr5mAnCPCX2Ab+mDZPiZCEgAhlZlD0CAwEAAaOCAbIwggGuMB0GA1UdDgQW BBS0onPdoR0b8y/GMTfwRbo8d1xQNDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEGMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAlO7T9ZxfR5t71R9QyyW/ L18LZoJCieBxVwQqUSNTwi8IprpilkdApNVdDd7goq/DUODMW+rz+s6/ztaiPjmryyaA3KK+AAwK etPtroH/0qfzmX0GN6gsw8vKm+ybPWXuhfjk0+vcsXhUQzPGpzN2i9LXjCg8p16AQpBjI9JkaEpM IJ7/0WG2ARzeB9XITWYfpk14MRqWvufHsXSp6aGHdA3qLpc+u53O/16Xkl6i8951nQmoNPRy1ePo QJg6ITIR8mbzkLlAaamMuYIz32ACaCk/lPHoA8H+29xTD+aC3gc6+pq8aS9SSgnxcQTC30CBdrOd LrbopvxGkCHDbM3bIzCCBO0wggPVoAMCAQICCjM4lI8AAAAAbpYwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNjAxMTQxNzMwMzlaFw0xOTAxMTMxNzMwMzlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA4xQ2hom9O5hwXTWlTDaY/fuIiWvivQHEzd8volNcoLbxxuHKLXgwX++2 TdbsHbfpaHVtAvF8huN7Lkn6Taf6MCzlBJRWoAJz6hwLwFCMLJeQI853KST/u/FIuLt+GjDbHXT/ kGbvRyNkIPj+njA9uY5I8m0/XUDMV2aTtqEwc55Vo2CCLXWYStQ1maiEdGre59mIwkkLGTV9JSeC cK7Yx2Ba2D552QtH9QdjO1eeCEvOtwhMn7uV6LaGcfGLh8GKSkhavNEhIenDAy3U3tWQI1sbJ28i guuK63krciNj1TfbgVnfjpXhqCAI1aIKTCiotKUkR3ArsA8BnpKUFbmyvQIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFPFPxYiZomy2ZdvinDW1VhNj2YqbMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQUwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQAW7r7P ZtIEuVPCSblXPqrbVdgVkNIw3qV6WHz/8TfK1UnETx3tkjFGhR+TjEYYXhiZHaIFlTZzK4x8UH6X 3NM/MqLZQ98cFxDVlGOTKEJqRBgdpLBaoDHddtW6s0d1mPOC3KLH6MNDKKZV7PJrzu056M8DPj7R mbNJqadj8wZL1nTW7Nq/+8FyT+v6S3ecz78sETYU4KFXtWjeIryJFPLL5CjIIL+WWjrKJ2lvCUun VGJr75NELwyUSEDUUdM6UKTiqfuFf14TGUYcUCdw41U44fUP6RypuwERYRa90ACeqHAo8syxeYrL GtVbIcexJQSJNHF4XqepizC6hjV92swJMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgozPVjXAAAAAG6eMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDYxNDExMTgyN1owLwYJKoZIhvcNAQkEMSIEILyPUUEydLlv Ab+DlUsgFSiHcfRjSizvq7ogEep6HZjjMAsGCSqGSIb3DQEBCwSCAQCRZUQqz8Z/phzYB7fx4Qmv 1fqeCYvoukD7KBC3zy4yDvQyuBO7W7Iq0gt64FUWNYCHaftSYT8SyoMEU9cwmEeBSbjCK/cOko6c bXRtQZ2xFcEL6QAhyTaQjEiJTfeFAYBIO8GvS02ADldPD4BM1Zd50gPQZ8+2hpRG3wKJEk0Og3n3 AFyZQfdNIqoUTjWjT5oUTL2arBGRJ33el3Mb3z6rHaXxuAOSLF62x66eTQy21FAJNEjJ0vyBUpXF Kui1n+UiVOeLhMZVlfxBF6LchDg6QB4Aj883N77mI7/LFfE1nHc1KrGnCOBA6Y4HaCQB8qFIEh+c DwzBUkG6rm5rKeFIAAAAAAAA --===============0735903836==-- From nobody Tue Jun 14 05:07:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370D012D533 for ; Tue, 14 Jun 2016 05:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfcZx8iDXGxr for ; Tue, 14 Jun 2016 05:07:19 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 B086B12DBAB for ; Tue, 14 Jun 2016 05:07:19 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id h190so64837802ith.1 for ; Tue, 14 Jun 2016 05:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/2BnchxoDJqhJXxcbpW6jCrjN6NALAdxN1w12c4C8vk=; b=L5nPkjnVniixVJ7fkOvpUj+R5QauFZ5BLmc1zaboPzl1GCIIrk6FOYE4kCQkoSjnfP ejIDHh3J7J5z23OsJU02etwaMgUFXR85mVNls3+7PGce96UgdNmPsQyKmB3R/sIxvtWe 6SqX9JRy9N3rd+D5z3pD90AaK3VD8my8eJhVz/++ao0NMKBmE35Zwtk6CNk3jN3WJTq1 QvfL3kkLwKiUZPagL3FruhN1vzkYigj0OJlULIXovGV50ZKbC+21uypbkzf1mGCkljmZ +B0P8+hTOlIN89Fd3vgtJZ2QEtGhvsU7QwgFP/Jo0qPV9FP/N3DW0OBUXoMHxFrbecVv 3fog== 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-transfer-encoding; bh=/2BnchxoDJqhJXxcbpW6jCrjN6NALAdxN1w12c4C8vk=; b=mKqjqG9p9vbMidR27rt5C0mLOLtiN88MMhoa+b/yA2E+5br2bs6SDNlr7I5jnrMtnZ rOfpf8CQpMEV0hZfg45i/vZPKyJ4tSD8i3v95v6lTAhX48VjyFvLC6o9V2CZMO9/HUAt AsJ33gTO7h9ptZU2wNyLvEvZ+31bXPgzlOJ2ylxig5gXQouTGQb+roMkF23xWUbCrs/7 oplwrzP9I4L3fZDrwA0qY3AI8N5YcwRUxA6cW25AaSIvvn2ver34yyL9sDVf0eJnSY1N OEXx1M5x7dvpCwERyVoqJDzllLtssb67YLz4N4GrgLNq50hbuGm05jWr6QR44r1Pg6Tv ozXA== X-Gm-Message-State: ALyK8tKHaLJM0EO6nMiXR1NYfbsJ+Vny9XnVSWu8sIyJ9QyUotYtx/4JrbarfNW0JWr8F7rtd9iGejC1nclMbw== X-Received: by 10.36.20.196 with SMTP id 187mr7301650itg.83.1465906038944; Tue, 14 Jun 2016 05:07:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.101.15 with HTTP; Tue, 14 Jun 2016 05:07:18 -0700 (PDT) In-Reply-To: References: <8760tc3kd0.fsf@alice.fifthhorseman.net> <3B833484-DFD8-419A-877C-C1F259AC4528@gmail.com> From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= Date: Tue, 14 Jun 2016 14:07:18 +0200 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 12:07:22 -0000 On Tue, Jun 14, 2016 at 1:22 PM, Watson Ladd wrote: > > On Jun 13, 2016 10:08 PM, "Karthikeyan Bhargavan" > wrote: >> >> I prefer (2) > > Same. It's clear 1 makes proofs more complicated, making mistakes easier = to > miss. Same here. I also find it unlikely that (1) actually has any significant positive effect (in the TLS case, unsure about DTLS) as it is probably easy for a passive observer to infer the content type from the data flow. --=20 Henrik Grubbstr=C3=B6m grubba@grubba.= org Roxen Internet Software AB grubba@roxen.com From nobody Tue Jun 14 05:12:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E7C12DBB8 for ; Tue, 14 Jun 2016 05:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNhaWHNbeSwK for ; Tue, 14 Jun 2016 05:12:15 -0700 (PDT) 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 AE42A12D542 for ; Tue, 14 Jun 2016 05:12:15 -0700 (PDT) Received: from [128.232.110.111] (c111.al.cl.cam.ac.uk [128.232.110.111]) (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 640A33E19 for ; Tue, 14 Jun 2016 14:12:14 +0200 (CEST) To: tls@ietf.org References: <8760tc3kd0.fsf@alice.fifthhorseman.net> From: Hannes Mehnert Message-ID: <764f87ac-92ee-c410-35ac-d4a2cf0e51ad@mehnert.org> Date: Tue, 14 Jun 2016 13:12:05 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <8760tc3kd0.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 12:12:18 -0000 On 13/06/2016 21:27, Daniel Kahn Gillmor wrote: > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: >> 1. Use the same key for handshake and application traffic (as in the >> current draft-13) >> > > or >> >> 2. Restore a public content type and different keys > > Given this choice, i prefer (1). FWIW, I prefer (1) as well hannes From nobody Tue Jun 14 05:45:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E38112D61A for ; Tue, 14 Jun 2016 05:45:32 -0700 (PDT) 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, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3Z2nny3TjCE for ; Tue, 14 Jun 2016 05:45:30 -0700 (PDT) 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 3101D12D5CC for ; Tue, 14 Jun 2016 05:45:30 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id v199so119578020wmv.0 for ; Tue, 14 Jun 2016 05:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=IBxqqVZYUDLXFWRjwcWWrt4AIs0Ld6HFdsorjD7qmDU=; b=B8mstItrAgzsr+qGe4EOea4sEDUT6+3xAyHRYIaq/I0t1N5e6e+EwTCJQ/xZ2IintD trhLABap4FP0VOSpTvcjL2x6g8kDs+Z5EK1BbYuZAbdPG7vx5YKJIAnmHWxFFhLiwfVp QBpA1ptH5xPk0kIFG+YxiabBwr36XN5BJCBdL5SYkA29b3Xpzt2EENkvaeDYrdhHYqNA TuCkdDz5tUNGWGAtkKCLxJHWagGb0dDtqsB90z5j/379UHRtteoHLsLkn2ZzGJFhHxNE kQ508L4ToL7ih7mdF8z4Jw/vJfi5gpZkrZAKPBPfs3DcUHPOmu5NVt2KhETwtJSfD1tE 3fhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=IBxqqVZYUDLXFWRjwcWWrt4AIs0Ld6HFdsorjD7qmDU=; b=FOP9xJxuvCDAQAMceGqE7yFvKidpsJiUlSu8oqbjeDibkm2lGCsKjLXqE/8S2dC1Jx 6208KRXk/s98nQVEDtnHGerNj6Vf5SzjCGySs2yaFTIZ17+A5/kixgeC8kGU3rilSsBh hUv6k7r9BemaHCBHuqWcvVTkPCBhS/xt0t+/sL8cEJTcVTOddpnNPh9q2cL8XsrNxChF 8AgmghbtrDs0n3ZYmEXigLp6yy2S7LdXhN97dGRIs9JqkAuPfH0Fmet8g5q3VVov1MuB tnX5YawRW70z8oN4Nsk4b067cAPjyd7KhdhpPEPkavgEQrg7y8BNN9uytFSUm2Yn3FOU fclA== X-Gm-Message-State: ALyK8tIkPLYt+0bH+M8CLf+xGGdRsmVvufU9wGt33K9sSR/z+6ZIqSr7TIgB2f2DHi3Osy/cNBpZwSkOWvhSSg== X-Received: by 10.194.150.130 with SMTP id ui2mr6124608wjb.11.1465908328731; Tue, 14 Jun 2016 05:45:28 -0700 (PDT) MIME-Version: 1.0 Sender: cas.cremers@gmail.com Received: by 10.28.46.18 with HTTP; Tue, 14 Jun 2016 05:45:08 -0700 (PDT) In-Reply-To: <764f87ac-92ee-c410-35ac-d4a2cf0e51ad@mehnert.org> References: <8760tc3kd0.fsf@alice.fifthhorseman.net> <764f87ac-92ee-c410-35ac-d4a2cf0e51ad@mehnert.org> From: Cas Cremers Date: Tue, 14 Jun 2016 13:45:08 +0100 X-Google-Sender-Auth: 2vWOay54G4F-lOa8YhQSNhpCtqs Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=089e0112beda3521ca05353c6162 Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 12:45:32 -0000 --089e0112beda3521ca05353c6162 Content-Type: text/plain; charset=UTF-8 It is not quite as simple as saying "(1) makes proofs more complicated" since it depends on what you are trying to prove. (1) makes some styles of standard AKE property proofs (key secrecy, authentication) harder (2) might make some privacy proofs harder Given that the proof-effort has mostly focused on secrecy and authentication properties, one can argue for (2). However, some proof styles can still work out in (1), so it is not such a clear choice. Over time, I've changed my mind, and I now prefer (2) (since we don't have full detail on any privacy proofs) as long as the content-type essentially boils down to a single bit of information (which key we are using) and nothing else. FWIW, Cas On Tue, Jun 14, 2016 at 1:12 PM, Hannes Mehnert wrote: > On 13/06/2016 21:27, Daniel Kahn Gillmor wrote: > > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: > >> 1. Use the same key for handshake and application traffic (as in the > >> current draft-13) > >> > > > or > >> > >> 2. Restore a public content type and different keys > > > > Given this choice, i prefer (1). > > FWIW, I prefer (1) as well > > > hannes > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e0112beda3521ca05353c6162 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It is not quite as simple as saying "(1) makes proofs= more complicated" since it depends on what you are trying to prove.
(1) makes some styles of standard AKE property proofs (ke= y secrecy, authentication) harder
(2) might make some pr= ivacy proofs harder

Given that the proof-eff= ort has mostly focused on secrecy and authentication properties, one can ar= gue for (2).
However, some proof styles can still work out in (1)= , so it is not such a clear choice.

Over time, I&#= 39;ve changed my mind, and I now prefer (2) (since we don't have full d= etail on any privacy proofs) as long as the content-type essentially boils = down to a single bit of information (which key we are using) and nothing el= se.

FWIW,

Cas


On Tue, Jun 1= 4, 2016 at 1:12 PM, Hannes Mehnert <hannes@mehnert.org> wro= te:
On 13/06/2016 21:27,= Daniel Kahn Gillmor wrote:
> On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:
>> 1. Use the same key for handshake and application traffic (as in t= he
>> current draft-13)
>>
>=C2=A0 > or
>>
>> 2. Restore a public content type and different keys
>
> Given this choice, i prefer (1).

FWIW, I prefer (1) as well


hannes

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

--089e0112beda3521ca05353c6162-- From nobody Tue Jun 14 11:37:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD9D12D8CB for ; Tue, 14 Jun 2016 11:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlDQC6axKgBS for ; Tue, 14 Jun 2016 11:37:02 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4995712D8C8 for ; Tue, 14 Jun 2016 11:37:02 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id C507C33D1BA; Tue, 14 Jun 2016 18:37:01 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C73F4C9CA49@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C9E044@uxcn10-5.UoA.auckland.ac.nz> <22902566.AuEvmjhU12@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4CA0C94@uxcn10-5.UoA.auckland.ac.nz> From: Geoffrey Keating Date: 14 Jun 2016 11:37:01 -0700 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CA0C94@uxcn10-5.UoA.auckland.ac.nz> Message-ID: Lines: 22 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Adoption of TLS-LTS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 18:37:03 -0000 Peter Gutmann writes: > Hubert Kario writes: > > >to be pedantic, the RFC describes itself "a profile" while in reality it > >modifies the protocol in a way that will make it incompatible with "vanilla" > >TLS 1.2 implementations > > Oh, right. Well that's easily fixed, I used "profile" because I > couldn't think of a better term, the best I could come up with is > "plan", but it's not really a plan either. If people think "plan" > is better than "profile", and it deals with Russ' objection, I'll > change it to that. Alternatively, if you can think of a better term > than "plan", let me know (or forever hold your peace :-). I think an appropriate title might be The Transport Layer Security (TLS) Protocol Version 1.2.1 Update because that's what this is, isn't it? It's a new version of the protocol with minor but significant changes. From nobody Tue Jun 14 11:56:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEFE12D8E4 for ; Tue, 14 Jun 2016 11:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HC6WwLdq2HF for ; Tue, 14 Jun 2016 11:56:55 -0700 (PDT) Received: from lnx503.hrz.tu-darmstadt.de (lnx503.hrz.tu-darmstadt.de [130.83.156.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1165512D8E7 for ; Tue, 14 Jun 2016 11:56:54 -0700 (PDT) Received: from smtp.tu-darmstadt.de (lnx505.hrz.tu-darmstadt.de [130.83.156.234]) by lnx503.hrz.tu-darmstadt.de (8.14.4/8.14.4/HRZ/PMX) with ESMTP id u5EIuqBE022386 for ; Tue, 14 Jun 2016 20:56:52 +0200 (envelope-from guenther@cs.tu-darmstadt.de) Received: from [130.83.73.96] by smtp.tu-darmstadt.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1bCtW7-0005y6-U7 for tls@ietf.org; Tue, 14 Jun 2016 20:56:52 +0200 To: tls@ietf.org References: <8760tc3kd0.fsf@alice.fifthhorseman.net> <764f87ac-92ee-c410-35ac-d4a2cf0e51ad@mehnert.org> From: =?UTF-8?Q?Felix_G=c3=bcnther?= Openpgp: id=2BAE4A6F7946461B700161B352AF0200D3F1700E; url=http://www.felixguenther.info/publickey.asc Message-ID: <5760536F.5040801@cs.tu-darmstadt.de> Date: Tue, 14 Jun 2016 20:56:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8AhED2Sb9H0TGD3I1Rc2glRR3QukjNCs1" X-PMX-TU: seen v1.2 by 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2016.6.14.184516 X-PMX-RELAY: outgoing Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 18:56:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8AhED2Sb9H0TGD3I1Rc2glRR3QukjNCs1 Content-Type: multipart/mixed; boundary="ios4doXBo4H0AfntL6hGgXCdLUCo4Gx5n" From: =?UTF-8?Q?Felix_G=c3=bcnther?= To: tls@ietf.org Message-ID: <5760536F.5040801@cs.tu-darmstadt.de> Subject: Re: [TLS] Consensus call for keys used in handshake and data messages References: <8760tc3kd0.fsf@alice.fifthhorseman.net> <764f87ac-92ee-c410-35ac-d4a2cf0e51ad@mehnert.org> In-Reply-To: --ios4doXBo4H0AfntL6hGgXCdLUCo4Gx5n Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I also prefer (2). Cheers, Felix On 14/06/2016 14:45 +0200, Cas Cremers wrote: > It is not quite as simple as saying "(1) makes proofs more complicated"= > since it depends on what you are trying to prove. >=20 > (1) makes some styles of standard AKE property proofs (key secrecy, > authentication) harder > (2) might make some privacy proofs harder >=20 > Given that the proof-effort has mostly focused on secrecy and > authentication properties, one can argue for (2). > However, some proof styles can still work out in (1), so it is not such= > a clear choice. >=20 > Over time, I've changed my mind, and I now prefer (2) (since we don't > have full detail on any privacy proofs) as long as the content-type > essentially boils down to a single bit of information (which key we are= > using) and nothing else. >=20 > FWIW, >=20 > Cas >=20 >=20 > On Tue, Jun 14, 2016 at 1:12 PM, Hannes Mehnert > wrote: >=20 > On 13/06/2016 21:27, Daniel Kahn Gillmor wrote: > > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: > >> 1. Use the same key for handshake and application traffic (as in= the > >> current draft-13) > >> > > > or > >> > >> 2. Restore a public content type and different keys > > > > Given this choice, i prefer (1). >=20 > FWIW, I prefer (1) as well >=20 >=20 > hannes >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --ios4doXBo4H0AfntL6hGgXCdLUCo4Gx5n-- --8AhED2Sb9H0TGD3I1Rc2glRR3QukjNCs1 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.17 (GNU/Linux) iEYEARECAAYFAldgU3MACgkQUq8CANPxcA7WHACeJbNT6XdQ3YR3y/eqD+1a/eVx TD8AniEUY17FNuXWAboNy8YkWGxb2LwT =67lV -----END PGP SIGNATURE----- --8AhED2Sb9H0TGD3I1Rc2glRR3QukjNCs1-- From nobody Tue Jun 14 12:01:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC96612DBDD for ; Tue, 14 Jun 2016 12:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VRXccO155uw for ; Tue, 14 Jun 2016 12:01:47 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6E31112D901 for ; Tue, 14 Jun 2016 12:01:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 8621F5C67; Tue, 14 Jun 2016 22:01:46 +0300 (EEST) 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 bwJAjjxpuAVZ; Tue, 14 Jun 2016 22:01:46 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-224-2.bb.dnainternet.fi [87.100.224.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 3B9FA21C; Tue, 14 Jun 2016 22:01:46 +0300 (EEST) Date: Tue, 14 Jun 2016 22:01:44 +0300 From: Ilari Liusvaara To: Yoav Nir Message-ID: <20160614190144.GA9787@LK-Perkele-V2.elisa-laajakaista.fi> References: <95ACB42E-A0FF-4E46-87E9-212DAF033F42@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <95ACB42E-A0FF-4E46-87E9-212DAF033F42@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 19:01:51 -0000 On Tue, Jun 14, 2016 at 11:33:11AM +0300, Yoav Nir wrote: > > > (1) +1 > One important (for me) use case for handshake messages after the > original handshake is client certificate authentication. Disclosing > that the user has just touched the magic resource that causes > certificate authentication reveals actual information about what > the user is doing. I haven’t seen an argument about why using the > same key is similarly harmful. I too haven't seen an argument (or am I able to construct one myself) on why using the same key causes more issues than "more difficult for cryptographers" (without assumptions known to be false or cause severe problems no matter what). Such arguments could include e.g. crypto screw (no proof of exploitability needed), implementability, narrowing works-vs- correct gap, etc... About every other issue I could come up with, it seems to be just as bad with separate keys and public content types (except those ones that are just worse with public content types of course). -Ilari From dowling.bj@gmail.com Tue Jun 14 12:36:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7463112D928 for ; Tue, 14 Jun 2016 12:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qt-gCnoRUJxy for ; Tue, 14 Jun 2016 12:36:27 -0700 (PDT) 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 A9B5E12D935 for ; Tue, 14 Jun 2016 12:36:26 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id q132so141333lfe.3 for ; Tue, 14 Jun 2016 12:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=NhshBeLImEcRElui1bzMUW8RbZtIITnX3c488klu3Bw=; b=q6DGghuRUh5i1/iEPftT+Y8RGC135D5hWThntlFh8OKwZXRGQ6tUPq6dHUq9CrjyRu qaOjP1qtqTokUPoQ3+KgjxgDRNGk9klnzyfMYQ4XWJnZGwOCN2tzm+JkbjLdSiPIh95m h8MyxZ/mYNXtdjS15j22M0nyjj8phXVMajIJBtxGhcq6FpwrW7iKCsrJ5jMS+MDDypx/ 91QIoWCfb+w+jrfZflzoMPvCxHXQFjsU0UCBaFjb9jg7xyIBpod3AyjbKjiKlIosqYth li0NTI94CKF2CbaWSUMJXbJmfQp3wvAQvPVv+6WeKDihLGSBO4uadUQwTfKUKOGTpJt0 4SLQ== 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; bh=NhshBeLImEcRElui1bzMUW8RbZtIITnX3c488klu3Bw=; b=MJRgABJdbNZTu/u8VQxh25SrCEq0B8UHuGdgaP3LGfg62qWtc8Xa5aHk74B657RjqJ xYAZS68SCmLT7E3npRnH40P/xfOZfrzTGS9FmZ9tY870pdKAAEspi9gkDVBIbiMjvFQ2 1QgILHMwjtIFGFMcdLD6hHPDsHSaku6iWXxWt+oiD1Zbwb+Vk8LN4fM2KSO4bhkaseCp Yi8LBgPXy+rov1oCrs50sZQKIR2KdCNf4ISDPfZjzWOG57ImL5szEko6iWBTX49xTKjO V9RAOWDi9XR8TTNnpVlXfvOfT0N0D5KwfGk2qYZImcvMbyQIDGDS0qftu/ehVNfxOXi7 nTPQ== X-Gm-Message-State: ALyK8tJYtQ4ap/ktcuRoVGvKx4rVfg6cIjyzH5OzkqA7fFEb7FYILGXx8zAhJFFkrThvXbMP7Ya4rzqasid84w== X-Received: by 10.25.145.2 with SMTP id t2mr2129556lfd.163.1465932984826; Tue, 14 Jun 2016 12:36:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.157.5 with HTTP; Tue, 14 Jun 2016 12:36:24 -0700 (PDT) From: Benjamin Dowling Date: Tue, 14 Jun 2016 20:36:24 +0100 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a11403bfad3402b0535421e47 Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 19:38:04 -0000 --001a11403bfad3402b0535421e47 Content-Type: text/plain; charset=UTF-8 I am in favour of option (2). Cheers Ben. --001a11403bfad3402b0535421e47 Content-Type: text/html; charset=UTF-8
I am in favour of option (2).

Cheers
Ben.
--001a11403bfad3402b0535421e47-- From nobody Tue Jun 14 13:43:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B33512D8D0 for ; Tue, 14 Jun 2016 13:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 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_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNlQKfsdkFGI for ; Tue, 14 Jun 2016 13:42:52 -0700 (PDT) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (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 ADE2E12D945 for ; Tue, 14 Jun 2016 13:42:32 -0700 (PDT) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-09v.sys.comcast.net with SMTP id CvAOb6hgVrlQrCvAOb84Yu; Tue, 14 Jun 2016 20:42:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465936952; bh=6s0hjD4aWIAEG/fZzPseK653In002m9/8bK2664pIj4=; h=Received:Received:Content-Type:From:Mime-Version:Subject:Date: Message-Id:To; b=CZRkLmxyoQnU94XFNSdrdhaC0azBUFPv9tWsBATgKidsfEc2Ig6aKw3+ePFWnO2Qf YDhrpfPE3Y86e/fFvvB1Ovq45awQb4NTsvPoYx4GLW5uqlBmEDb20c8aerly2ISG5P vioT8xhyA/BgCo1tHYgEby/QU1+psj93/4LE2gpI3UC8akc55bykFfnJc0qo8WM5TS y3FAHn4NbjNXiCM6Axf4RqGOdA9I8MutVp9s9HRVAZfza+qFMwL/uoaYugn3G3chgT Ok+JwP0BDod+jV8tGyMnbJKTBxzZ7tI/EEsB8ujbszX2+SJ9fpxTZz95/jqCYkPtST JVS47oToLTjCQ== Received: from [21.180.21.60] ([172.56.42.91]) by resomta-po-15v.sys.comcast.net with comcast id 6ki01t00Q1y0zMG01ki6Mq; Tue, 14 Jun 2016 20:42:27 +0000 Content-Type: multipart/alternative; boundary=Apple-Mail-D34E5767-0099-485D-ACCB-B0B02906B673 Content-Transfer-Encoding: 7bit From: Will Serumgard Mime-Version: 1.0 (1.0) Date: Tue, 14 Jun 2016 12:13:13 -0700 Message-Id: References: <8760tc3kd0.fsf@alice.fifthhorseman.net> <3B833484-DFD8-419A-877C-C1F259AC4528@gmail.com> In-Reply-To: To: Watson Ladd X-Mailer: iPhone Mail (13F69) Archived-At: Cc: Karthikeyan Bhargavan , tls@ietf.org Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 20:42:57 -0000 --Apple-Mail-D34E5767-0099-485D-ACCB-B0B02906B673 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +2 Will Serumgard > On Jun 14, 2016, at 4:22 AM, Watson Ladd wrote: >=20 >=20 > On Jun 13, 2016 10:08 PM, "Karthikeyan Bhargavan" wrote: > > > > I prefer (2) >=20 > Same. It's clear 1 makes proofs more complicated, making mistakes easier t= o miss. >=20 > > > > > On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor w= rote: > > > > > > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: > > >> 1. Use the same key for handshake and application traffic (as in the > > >> current draft-13) > > >> > > >> or > > >> > > >> 2. Restore a public content type and different keys > > > > > > Given this choice, i prefer (1). > > > > > > --dkg > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-D34E5767-0099-485D-ACCB-B0B02906B673 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
+2

Will Serumgard


On Jun 14, 2016, at 4:22 AM, Watson Ladd <watsonbladd@gmail.com> wrote:


On Jun 13, 2016 10:08 PM, "Karthikeyan Bhargavan" <karthik.bhargavan@gmail.com> wrote:
>
> I prefer (2)

Same. It's clear 1 makes proofs more complicated, making mistakes easier to miss.

>
> > On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> >
> > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:
> >> 1. Use the same key for handshake and application traffic (as in the
> >> current draft-13)
> >>
> >> or
> >>
> >> 2. Restore a public content type and different keys
> >
> > Given this choice, i prefer (1).
> >
> >      --dkg
> >
> > _______________________________________________
> > 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

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--Apple-Mail-D34E5767-0099-485D-ACCB-B0B02906B673-- From nobody Tue Jun 14 13:45:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAD212D9A8 for ; Tue, 14 Jun 2016 13:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eng.ucsd.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GYD3I7vXMYk for ; Tue, 14 Jun 2016 13:45:21 -0700 (PDT) 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 4002C12D8D0 for ; Tue, 14 Jun 2016 13:45:21 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id n184so137828951wmn.1 for ; Tue, 14 Jun 2016 13:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eng.ucsd.edu; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :references:in-reply-to:to; bh=G2qRiLGht/KeyE/BJBM60VPFi3fQY3WMfmOacmWQ9MA=; b=aU98wsE8dqF+L4440+4tdtisf4GA44oP7GqfcZxbGy64lJBQVpekIU0KxlnVAY4lcQ 7gZayMd2IMuVLTA0XBcPAK7i+ibku8Bia0nKufeNPky7Ek0R+iSNK/0lJP8/6HKdssle O0K7fYisCdL9cpWIrxlUODnNrE8uJ5IUyfwsQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:references:in-reply-to:to; bh=G2qRiLGht/KeyE/BJBM60VPFi3fQY3WMfmOacmWQ9MA=; b=TOAKAGdGiZ87GdvML8ztLfnZ7I11/K+sU32krGrEtZGXBo71z6mCuXpAr4pyOUr8O0 H3aBM1yBn+qLAtFS3JLGDcIvQFanfWhZY2Fcw2Ds6D2XMH3/B3CGhcwmm0EOAvDYRE6z 0+8u2/S614xa/azarFwDa5S+04YFrTUso+sLEyGT445c5CZnAAKK6piLP/e1zY937vSE AmefFiqVzm4hfQgHKDlxDEjLTFkkmUSFjnEULT2y0npcS8D6A3oBKMnE31M1csZrwHcL GgPEdIhOU7Ar4aTyQ/tgE/zu9H3IfwKBS5VsFnsZ8gC+OGQrjJNu9TwRtQzD9vA54LT8 j2LA== X-Gm-Message-State: ALyK8tJ4Nyem2+ynAybujmexOL/GJTvbqa0+KQfcV2ICgsbO9b7935gukrnRXfdN6nfJpucB X-Received: by 10.194.75.196 with SMTP id e4mr7717284wjw.44.1465937119695; Tue, 14 Jun 2016 13:45:19 -0700 (PDT) Received: from [192.168.0.14] ([31.10.154.188]) by smtp.gmail.com with ESMTPSA id s10sm34820406wjt.29.2016.06.14.13.45.18 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 14 Jun 2016 13:45:19 -0700 (PDT) From: =?utf-8?Q?Bj=C3=B6rn_Tackmann?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: Date: Tue, 14 Jun 2016 22:45:17 +0200 References: <20160614111828.18296913.41202.73993@ll.mit.edu> In-Reply-To: <20160614111828.18296913.41202.73993@ll.mit.edu> To: tls@ietf.org X-Mailer: iPhone Mail (13F69) Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 20:45:24 -0000 Just to be clear: the "+1" I sent earlier meant "I agree with Karthik" -- so= it means solution (2). > On Jun 14, 2016, at 1:18 PM, Blumenthal, Uri - 0553 - MITLL wrote: >=20 > Key reuse often ends up causing problems. IMHO a more sound approach is (2= ). IMHO it isn't prohibitively expensive either. >=20 > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE netwo= rk. > Original Message =20 > From: Bj=C3=B6rn Tackmann > Sent: Tuesday, June 14, 2016 05:23 > To: tls@ietf.org > Subject: Re: [TLS] Consensus call for keys used in handshake and data m= essages >=20 > +1 >=20 >=20 >> On Jun 14, 2016, at 7:08 AM, Karthikeyan Bhargavan wrote: >>=20 >> I prefer (2) >>=20 >>> On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor wr= ote: >>>=20 >>> On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: >>>> 1. Use the same key for handshake and application traffic (as in the >>>> current draft-13) >>>>=20 >>>> or >>>>=20 >>>> 2. Restore a public content type and different keys >>>=20 >>> Given this choice, i prefer (1). >>>=20 >>> --dkg >>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jun 14 14:37:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DE212B046 for ; Tue, 14 Jun 2016 14:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70Yw0QhCpvzz for ; Tue, 14 Jun 2016 14:37:19 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 1E48012D804 for ; Tue, 14 Jun 2016 14:36:35 -0700 (PDT) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u5ELXrNa003430; Tue, 14 Jun 2016 14:36:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=pT0Hy99RipMtKApr366JbwJraTs6AV4fBGLYqZN6M/Y=; b=HuQSR+Vo7P14kJuVnOEWgBvTIFPKL1b/fXhv9G5bAratMEzKNx4oviGfv2beXH0cDD6w j5Jv4q7UFB/BQ0wEqDEtxdJGk/TZW+XXxo2aVtuGlVorqmSRArJLVhqrxvgot9+OUOX/ 0HQr8C9WcXC+Xd8eyV6LML3U8oz5AD6rTVM= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 23jp4hs3gs-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Jun 2016 14:36:34 -0700 Received: from PRN-MBX01-4.TheFacebook.com ([169.254.3.192]) by PRN-CHUB06.TheFacebook.com ([fe80::f073:2a60:c133:4d69%12]) with mapi id 14.03.0294.000; Tue, 14 Jun 2016 14:36:33 -0700 From: Subodh Iyengar To: =?iso-8859-1?Q?Bj=F6rn_Tackmann?= , "tls@ietf.org" Thread-Topic: [TLS] Consensus call for keys used in handshake and data messages Thread-Index: AdHGLnRIplwqVOTRs0O5vfeZKe8kxgAieCOA//+W02o= Date: Tue, 14 Jun 2016 21:36:32 +0000 Message-ID: <974CF78E8475CD4CA398B1FCA21C8E9956548B6C@PRN-MBX01-4.TheFacebook.com> References: <20160614111828.18296913.41202.73993@ll.mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-14_09:, , signatures=0 Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2016 21:37:21 -0000 With option (2) would the keys end up being independent anyway? I think we = might need to share the sequence number space between the handshake message= s and the application data messages to avoid truncation attacks. I might ha= ve missed this, but was there a proposal to deal with sequence numbers for = option (2). =0A= =0A= I prefer option (1) since it actually offers some privacy guarantees. =0A= =0A= Subodh=0A= ________________________________________=0A= From: TLS [tls-bounces@ietf.org] on behalf of Bj=F6rn Tackmann [btackmann@e= ng.ucsd.edu]=0A= Sent: Tuesday, June 14, 2016 1:45 PM=0A= To: tls@ietf.org=0A= Subject: Re: [TLS] Consensus call for keys used in handshake and data mes= sages=0A= =0A= Just to be clear: the "+1" I sent earlier meant "I agree with Karthik" -- s= o it means solution (2).=0A= =0A= > On Jun 14, 2016, at 1:18 PM, Blumenthal, Uri - 0553 - MITLL wrote:=0A= >=0A= > Key reuse often ends up causing problems. IMHO a more sound approach is (= 2). IMHO it isn't prohibitively expensive either.=0A= >=0A= > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE netw= ork.=0A= > Original Message=0A= > From: Bj=F6rn Tackmann=0A= > Sent: Tuesday, June 14, 2016 05:23=0A= > To: tls@ietf.org=0A= > Subject: Re: [TLS] Consensus call for keys used in handshake and data = messages=0A= >=0A= > +1=0A= >=0A= >=0A= >> On Jun 14, 2016, at 7:08 AM, Karthikeyan Bhargavan wrote:=0A= >>=0A= >> I prefer (2)=0A= >>=0A= >>> On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor w= rote:=0A= >>>=0A= >>> On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:=0A= >>>> 1. Use the same key for handshake and application traffic (as in the= =0A= >>>> current draft-13)=0A= >>>>=0A= >>>> or=0A= >>>>=0A= >>>> 2. Restore a public content type and different keys=0A= >>>=0A= >>> Given this choice, i prefer (1).=0A= >>>=0A= >>> --dkg=0A= >>>=0A= >>> _______________________________________________=0A= >>> TLS mailing list=0A= >>> TLS@ietf.org=0A= >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_tls&d=3DCwIGaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-= wAyN7fQ&m=3D51hv3XazVlAM5-C2nNBPsem5FotA1PNxnRQasbSa0sc&s=3DwAkXyaR6H8OBIwk= PYvnVJClJb5pdbQKYE9gf6wApqB4&e=3D=0A= >>=0A= >> _______________________________________________=0A= >> TLS mailing list=0A= >> TLS@ietf.org=0A= >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_tls&d=3DCwIGaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-w= AyN7fQ&m=3D51hv3XazVlAM5-C2nNBPsem5FotA1PNxnRQasbSa0sc&s=3DwAkXyaR6H8OBIwkP= YvnVJClJb5pdbQKYE9gf6wApqB4&e=3D=0A= >=0A= > _______________________________________________=0A= > TLS mailing list=0A= > TLS@ietf.org=0A= > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_tls&d=3DCwIGaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wA= yN7fQ&m=3D51hv3XazVlAM5-C2nNBPsem5FotA1PNxnRQasbSa0sc&s=3DwAkXyaR6H8OBIwkPY= vnVJClJb5pdbQKYE9gf6wApqB4&e=3D=0A= >=0A= >=0A= > _______________________________________________=0A= > TLS mailing list=0A= > TLS@ietf.org=0A= > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_tls&d=3DCwIGaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wA= yN7fQ&m=3D51hv3XazVlAM5-C2nNBPsem5FotA1PNxnRQasbSa0sc&s=3DwAkXyaR6H8OBIwkPY= vnVJClJb5pdbQKYE9gf6wApqB4&e=3D=0A= =0A= _______________________________________________=0A= TLS mailing list=0A= TLS@ietf.org=0A= https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_tls&d=3DCwIGaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN= 7fQ&m=3D51hv3XazVlAM5-C2nNBPsem5FotA1PNxnRQasbSa0sc&s=3DwAkXyaR6H8OBIwkPYvn= VJClJb5pdbQKYE9gf6wApqB4&e=3D=0A= From nobody Wed Jun 15 01:01:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7478412B018 for ; Wed, 15 Jun 2016 01:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.348 X-Spam-Level: X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-NTa-G41hvu for ; Wed, 15 Jun 2016 01:00:58 -0700 (PDT) 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 70BD112D096 for ; Wed, 15 Jun 2016 01:00:58 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8CAE037E62; Wed, 15 Jun 2016 08:00:57 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.106]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5F80t6E008822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Jun 2016 04:00:56 -0400 Message-ID: <1465977655.20266.3.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Joseph Salowey , "tls@ietf.org" Date: Wed, 15 Jun 2016 10:00:55 +0200 In-Reply-To: References: 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.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 15 Jun 2016 08:00:57 +0000 (UTC) Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2016 08:01:00 -0000 On Mon, 2016-06-13 at 12:00 -0700, Joseph Salowey wrote: > For background please see [1]. > > Please respond to this message indicating which of the following > options you prefer by Monday June, 20, 2016  > > 1. Use the same key for handshake and application traffic (as in the > current draft-13) > > or > > 2. Restore a public content type and different keys Unless participants are really expert on what is the issue is and how these proofs are constructed, I doubt that people in the TLS WG can resolve that in a way that provides assurance. There are good arguments presented in the thread by few cryptographers, but since this is mainly a low level crypto decision, why not ask the CFRG instead? regards, Nikos From nobody Wed Jun 15 01:45:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF3112D0CB for ; Wed, 15 Jun 2016 01:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtXXyw7h2Vid for ; Wed, 15 Jun 2016 01:45:04 -0700 (PDT) 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 7530512B04B for ; Wed, 15 Jun 2016 01:45:03 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id v199so153017752wmv.0 for ; Wed, 15 Jun 2016 01:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xqPRrxk15DCb9W2kigo+950FvW1r5QegH1wLEN8YoCo=; b=jDU7M1yPkayeESoVwFnrRRhO9VLSlTF4Xm+KFME5rSBzzinnN8oLjVKO2K8A2WuomZ 0p4hQi+RB7mgSt7UF9J8ncrgx8TzyvotP4+I09miYbQANIAJUewuuDbrcC0jMadO5cTF ZkUCubB14ZPw0z6oVd9H2U/Kd5fnwkDj9Vbmt+VU6oYD3VAumKmCttfGtHHnkXWH5Yi9 oDPqBttgAxvatYNh183R3KB2U40nhlyYAxsEX4gzt9xoiL/9VFju335ifX4gDpaYCHGh S+dG4IoinAPU7yKAMrVAaaDq9UVsrj/SLzQi4NQ/5uO/yrb5m3AxwDIo8ZS3pl68VW9C nSgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xqPRrxk15DCb9W2kigo+950FvW1r5QegH1wLEN8YoCo=; b=NtFKanp4D7g57rrYkd/p8BISEZDQuwMq8uh8HRz85P044EV7AbR3TEEQvpTUJ9j4Vd A+qkfGNtQ50zJkk4SS46PjDjuyndyPBG10YjBmy5nVOOSmMbsCt9TBTkHlRbKF16L9nY hK9ato3lscnszHNf1oPyh6vjPFCYt/V5qM5hx73kusWbLmSK2Jr1gYi20NBnQmyoD/Fr 9IEXORoV6NpAv0uzaENAzZDoQNvneu2d7o4hnRoZzfzkxxLi5ALEpbVfNyampJyzz57n emcQRN3xdOYVTgqGyNlIQ+9K+bJgkRJAJ8+Q4x7rit61uHEIOMdXF4EyBRtzAbGe7du7 UOuQ== X-Gm-Message-State: ALyK8tIIcTgtdVi5g63NG8keJU3GK7L0tSVeoGHwHX+X2DLYY/Ds17SKHBMyYa1cZAbZog== X-Received: by 10.28.109.198 with SMTP id b67mr10733922wmi.53.1465980301831; Wed, 15 Jun 2016 01:45:01 -0700 (PDT) Received: from [172.24.248.248] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id u4sm37202695wjz.4.2016.06.15.01.45.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Jun 2016 01:45:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <1465977655.20266.3.camel@redhat.com> Date: Wed, 15 Jun 2016 11:44:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <26741B4E-3C0F-4E0C-AB44-F7DFCCEFED53@gmail.com> References: <1465977655.20266.3.camel@redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2016 08:45:05 -0000 Hi, Nikos > On 15 Jun 2016, at 11:00 AM, Nikos Mavrogiannopoulos = wrote: >=20 > On Mon, 2016-06-13 at 12:00 -0700, Joseph Salowey wrote: >> For background please see [1]. >>=20 >> Please respond to this message indicating which of the following >> options you prefer by Monday June, 20, 2016=20 >>=20 >> 1. Use the same key for handshake and application traffic (as in the >> current draft-13) >>=20 >> or >>=20 >> 2. Restore a public content type and different keys >=20 > Unless participants are really expert on what is the issue is and how > these proofs are constructed, I doubt that people in the TLS WG can > resolve that in a way that provides assurance. There are good = arguments > presented in the thread by few cryptographers, but since this is = mainly > a low level crypto decision, why not ask the CFRG instead? I disagree that this is a low level crypto decision, or at least that = this is mainly so.=20 There is the question of whether using the same key for application data = and handshake is harmful. That question is mainly low level crypto and = could be asked of CFRG. There is the other question of whether exposing the fact that there are = handshake messages and when they occur is harmful. That is = security-related, but not at all related to crypto. Weighing these two potential harms against each other and coming to a = decision is entirely an engineering issue, and we should not offload = that to CFRG. Yoav From nobody Wed Jun 15 04:11:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F170F12D105 for ; Wed, 15 Jun 2016 04:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeaEz_Xnjs7b for ; Wed, 15 Jun 2016 04:11:10 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 B3E2112D1A6 for ; Wed, 15 Jun 2016 04:11:10 -0700 (PDT) Received: by mail-pa0-x232.google.com with SMTP id bz2so6692997pad.1 for ; Wed, 15 Jun 2016 04:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=h5xHWR1qhtkEb2C0Jq0kR0xfcurN2sjBnNBu1wX+UX8=; b=AhgW/n0W9T8m0vwWHgG8zZ7z2PNcvBMOYDBGUtWq4HfLlNFm365VDEG6+omQmjaIEx kWPNlPlqao0C9lzDXlWWTKx7KomgV34DSa6VAmTowDvuisQDJj48G6G3GWakBmqnIbT1 3zY24A9MRhU3NTPlICHwrJa+h9zuQw3ZOGjRo= 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:from:in-reply-to:date:cc :message-id:references:to; bh=h5xHWR1qhtkEb2C0Jq0kR0xfcurN2sjBnNBu1wX+UX8=; b=lZO4l98Qi/eyfHpDQQUAF+FPL7l54egsXAlokOb4+7naP0SI0eVgkmgK2HQY0blgy/ QR+hzD9LOXhH1w8NsyRACjGUWet9g3LNP+MsIaIZLfGHW2RdW9qr+8r4lTBI5jbVcA/6 jKgfn6Hcz32O9rtfs3eqtwB63E8/WUjM7z8cmqOai6llExFquqznY8mewYPKf0467FVG GqBF/UxtqC6LlWPN6kkYrqqkPuwvq35r02QTh1Pa7VcoDVUtSg1xXMhs4ckrkZ0tsnMx jzIQYcrpgrLo2IAoLr77hZyIZCWZ6GAJNXrR82/pSjmgidEwwoqMktLTeehBbrhZ40o7 Y6Xg== X-Gm-Message-State: ALyK8tI80j+Ns2GawP45NIsr9I9OjvC6Uk211kAC/wGFLBQ9d0A+GCAWLIwoLAWmudinpQ== X-Received: by 10.66.148.105 with SMTP id tr9mr3296888pab.72.1465989070128; Wed, 15 Jun 2016 04:11:10 -0700 (PDT) Received: from [192.168.1.234] ([114.121.162.161]) by smtp.gmail.com with ESMTPSA id s65sm39520440pfd.23.2016.06.15.04.11.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Jun 2016 04:11:08 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_535605D6-D879-43FF-B933-04DE4D514EEF"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Aaron Zauner In-Reply-To: Date: Wed, 15 Jun 2016 19:11:03 +0800 Message-Id: <3C9FD4F6-DF09-49D9-B800-5D1C38138189@azet.org> References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C817BE@uxcn10-5.UoA.auckland.ac.nz> <54302B87-4730-4B8E-9F55-B33B89425A51@azet.org> <53384A13-5F80-4CF0-BD8F-F68E304ADF15@azet.org> <3B2C6D5A-939E-4539-B902-D4502EB9739C@azet.org> <96CBAD0F-0F0A-4095-81FD-09EE804EB7F6@azet.org> <1367F829-067E-4449-AB53-5357945BA9B1@azet.org> To: Joseph Lorenzo Hall X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" , RFC Errata System Subject: Re: [TLS] [Technical Errata Reported] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2016 11:11:12 -0000 --Apple-Mail=_535605D6-D879-43FF-B933-04DE4D514EEF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 14 Jun 2016, at 19:25, Joseph Lorenzo Hall wrote: >=20 > s/it's/its/ in one place in your errata text, Aaron. Thank you. I suggest the RFC Errata editors change text and further = additions/recommendations by others along the way when publishing (if = that's the right way to proceed, I'm quite unfamiliar with the errata = process and the information on it is a bit terse, to be honest). Aaron --Apple-Mail=_535605D6-D879-43FF-B933-04DE4D514EEF 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----- iQIcBAEBCgAGBQJXYTfIAAoJEOTbZJL9ubXVyGMQALUNJpgVVL3RkW6pdo0bnNus X9P6Ewgt7BtXfMpqxkgxp1afHl2XKJ/9fDziamR3kLga8lS6jxTrRpJileNh6kZA eWtXQt5NjXD1JNgZhmGX7LKGhA2FQ48yzzpaF06ZrKY7hlQVLMz7netHILPbNBuj QMxVVX6hvplRhc0JRbXIZYE4y9zk9oRzAhTgA12tkjQwWkeTyjCAt/i1+HENF2rW c71gQjzEQM19wtLPdTAzmCgneg2YRP24fGbCq2mKfaLBKYCUzOwonuNgI5xJp6AD yHpzz3aRgIoINKcCW+GAVlZu5LMcUiNABWdYppjE/vPS1NUKoWABZlVtXMO0Vs8+ WRIfeD3SkFPi79CM4Bg8EUO8VS6IMShmFQBqhE8Fh6llC9UgicoxK+uTT9mdhYU0 ROYsvtXMRAKEkbfFQgpLeaJ353kWEBgmNsTcPxkKq2HZpjix8l6Pv+yqDpd+aBfm WkwO269r8ALENMXg+ZK0kUvXhovJgT6mjUPtOeLNJ2ZHryudCgj/uisDnReOaadG /U6m8g0+KRzR4lnJpNwsn5J7mZcgvt7iaW2WAUI194mHoo5mp+f6QcR5wy3EtnKu 2laKhLbjoSeeRTICPn27gSyUcLlG2ghIp948q3lIE7crMy6ou6qOdc2nfKwv7Jm7 lokuELAnSIz2rKm++2IA =msaj -----END PGP SIGNATURE----- --Apple-Mail=_535605D6-D879-43FF-B933-04DE4D514EEF-- From nobody Wed Jun 15 06:44:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF2212D69B for ; Wed, 15 Jun 2016 06:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heSfNBfgQQEh for ; Wed, 15 Jun 2016 06:44:23 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id BCC3F12D60E for ; Wed, 15 Jun 2016 06:44:23 -0700 (PDT) Received: from fifthhorseman.net (unknown [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 80EA2F98B; Wed, 15 Jun 2016 09:44:22 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 3357521EB9; Wed, 15 Jun 2016 09:44:22 -0400 (EDT) From: Daniel Kahn Gillmor To: Yoav Nir , Nikos Mavrogiannopoulos In-Reply-To: <26741B4E-3C0F-4E0C-AB44-F7DFCCEFED53@gmail.com> References: <1465977655.20266.3.camel@redhat.com> <26741B4E-3C0F-4E0C-AB44-F7DFCCEFED53@gmail.com> User-Agent: Notmuch/0.22+69~gd812194 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 15 Jun 2016 09:44:18 -0400 Message-ID: <871t3y1s99.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2016 13:44:25 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote: > I disagree that this is a low level crypto decision, or at least that thi= s is mainly so.=20 > > There is the question of whether using the same key for application data = and handshake is harmful. That question is mainly low level crypto and coul= d be asked of CFRG. > > There is the other question of whether exposing the fact that there are h= andshake messages and when they occur is harmful. That is security-related,= but not at all related to crypto. > > Weighing these two potential harms against each other and coming to a dec= ision is entirely an engineering issue, and we should not offload that to C= FRG. To be clear, we're being asked to trade these things off against each other here, but there are other options which were ruled out in the prior framing of the question which don't rule either of them out. In particular, if we're willing to pay the cost of a slightly more complex key schedule (and an increased TLS record size), we could have "packet header" keys which protect the content-type itself for all non-cleartext TLS records. If we do that, these keys might as well also be used to protect the TLS record size itself. This would result in an opaque data stream (though obviously record size would still leak in DTLS, and timing and framing is still likely to leak the record size in the lowest-latency TLS applications). The current framing of the question pits these things against each other as a tradeoff, but if we want to, we could protect them all. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXYVuzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKIbAQAJ8+gPhKm5lfH0GAkF2cQ517 SKfe71P/SkBrU3vE7OUVOxYYAgrJ0PO88ycXCUTA2bbWm4UWQ+cmPJHPGv6rMIiD swh7m96LLxYfjqFbfKz7cfSgt1S98CdWaa+rpyjY1CjC6Pxyzu/cfzH9nCI6OpZF 3H6RX5EjHzU5ijU96lJs+ngQVm9y78Q0agkcanFjkClcOnwYsBx6tnKl+Pj1zJft 3C+99p87acqgrt8jWV3lDhBwEgPGRQLP7ykPXRM81RoZ/tjLPmJH+n6irMw1nawo FR1JQ4acgUPmZYqEpXfHR+G6CTy8aDbgunW5vdktTqHsBMQKf0Ac6UWdZglGjDSI p3hip2OuE+BUEoBVOtm4+yRPd11UuRdRR7zMXeAnSkm6jhNQEQuPmO9Jf4A/5x0t 56PEJKYBCeJCkH0OaV5PW8iX5MF5pZpSyXZ68bRdIS0JQkxAKATVIz1bGXIJsCFB 19iy8ox6vfu0dQY6ARK0fXqa0OtP/U4HBfJ4wCnAXtngyhan1jES9iHLoMipMR// rK64mFMPHg/r+hqB1eyeffynNZZlkuLM12k/tjX4n4KFY1iOL73ZKycA/pZQgmYg 38JcSiXwCjL0um+Hzdd10DCVn5v7zV3yGEQ0mPWJZ3DtMKAT4V0qavbSjHfspCv4 0JlEZmwHpYbHlYjAwGBC =k4iL -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 15 09:23:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E7612D1B3 for ; Wed, 15 Jun 2016 09:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wr0JHxSoX1bf for ; Wed, 15 Jun 2016 09:23:43 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id EA81812B013 for ; Wed, 15 Jun 2016 09:23:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id C89208498 for ; Wed, 15 Jun 2016 19:23:40 +0300 (EEST) 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 kOlP5UFB4bGE for ; Wed, 15 Jun 2016 19:23:40 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-224-2.bb.dnainternet.fi [87.100.224.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 89B922310 for ; Wed, 15 Jun 2016 19:23:40 +0300 (EEST) Date: Wed, 15 Jun 2016 19:23:38 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160615162338.GA10695@LK-Perkele-V2.elisa-laajakaista.fi> References: <1465977655.20266.3.camel@redhat.com> <26741B4E-3C0F-4E0C-AB44-F7DFCCEFED53@gmail.com> <871t3y1s99.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <871t3y1s99.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2016 16:23:45 -0000 On Wed, Jun 15, 2016 at 09:44:18AM -0400, Daniel Kahn Gillmor wrote: > On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote: > > To be clear, we're being asked to trade these things off against each > other here, but there are other options which were ruled out in the > prior framing of the question which don't rule either of them out. > > In particular, if we're willing to pay the cost of a slightly more > complex key schedule (and an increased TLS record size), we could have > "packet header" keys which protect the content-type itself for all > non-cleartext TLS records. If we do that, these keys might as well also > be used to protect the TLS record size itself. This would result in an > opaque data stream (though obviously record size would still leak in > DTLS, and timing and framing is still likely to leak the record size in > the lowest-latency TLS applications). Does this need to enlarge TLS record size? Why doesn't encrypting the content-type/length and then authenticating those off main MAC work (that's how SSH with CHACHA20-POLY1305 does things)? I presume problems from header-flipping (tho in TLS that will kill the connection if you try...) Also, in DTLS, there could be issues switching the encryption on (but then, looks like DTLS 1.3 has other unsolved problems currently..) -Ilari From nobody Wed Jun 15 09:51:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DD812D9E3 for ; Wed, 15 Jun 2016 09:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbOzBRUmc-Tz for ; Wed, 15 Jun 2016 09:51:29 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0B112D9DF for ; Wed, 15 Jun 2016 09:51:29 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 8AB4310224008; Wed, 15 Jun 2016 09:51:28 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 15 Jun 2016 09:51:29 -0700 (PDT) Message-ID: In-Reply-To: References: Date: Wed, 15 Jun 2016 09:51:29 -0700 (PDT) From: "Dan Harkins" To: "Joseph Salowey" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2016 16:51:30 -0000 Hello, On Mon, June 13, 2016 12:00 pm, Joseph Salowey wrote: > For background please see [1]. > > Please respond to this message indicating which of the following options > you prefer by Monday June, 20, 2016 > > 1. Use the same key for handshake and application traffic (as in the > current draft-13) > > or > > 2. Restore a public content type and different keys I prefer (1). Dan. From nobody Wed Jun 15 10:41:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0CB12DA7D for ; Wed, 15 Jun 2016 10:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrglE_B8fB0B for ; Wed, 15 Jun 2016 10:41:33 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001: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 3061612D7A6 for ; Wed, 15 Jun 2016 10:41:33 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id t74so19997506ioi.0 for ; Wed, 15 Jun 2016 10:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6MlHSK1YjqdUIA2zy5CowBmUgbdy5SDYVGZfGCVVfRc=; b=J7wY5KmxHOeyniAcrIF4mlstICaYlOVMxewTutuCDUJ60ycbAHXLZoyrCVKavv1wEk BSXNNqppxYNYvuyqwmZ3TcrmzUDAvysgYiqn0z8V7rdDr35uqu6ZdSQ8+V9zaVJ+Zhw4 oFFYlVbFQBSRe/7BG0l0r+hw3wUT8ivxHXrQg= 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; bh=6MlHSK1YjqdUIA2zy5CowBmUgbdy5SDYVGZfGCVVfRc=; b=mwJSlZ+cgaS6G8E4MDioJX9/5xJfLtv0xoiwo6ByK8NzBuPX0fJ5682BDvaev5W69m Hha+iaEo1GHPqVjMxOUMi9KeKGadru1qGkHk9AX0N7pFi5hO9VmfsNfp6emSfWfrLekh ou+B+rgQLISSFAs8BkgApR56ZBNACMkhi4YcvKDzslK+ipMOk7dmqZgbGJekISG0eA+B bfdAgJNoIPEx9Na8XrOYN9gLFJxABUsKzyrXtMdUm+6MmzQ/mcR7qwSNZtQj8/5Djy7S 5CDTFFE4fYSxv9lpi8NLGM+bXeqr2P4AMYXzARIW5mNKaq3yXqG8q3dQIQ6mltYXCKGc syvg== X-Gm-Message-State: ALyK8tKXJAW5WnsIopEBBm9WKJf99Gq0jdhkgfgkT2LrvNHtEoHusMzj1DATX2OXJ5AoaXwQEDQZE6hXTddzBjy8 X-Received: by 10.107.46.158 with SMTP id u30mr1057697iou.162.1466012492460; Wed, 15 Jun 2016 10:41:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Wed, 15 Jun 2016 17:41:22 +0000 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113ac342d986eb053554a107 Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2016 17:41:35 -0000 --001a113ac342d986eb053554a107 Content-Type: text/plain; charset=UTF-8 I prefer (1) On Wed, Jun 15, 2016 at 5:51 PM Dan Harkins wrote: > > Hello, > > On Mon, June 13, 2016 12:00 pm, Joseph Salowey wrote: > > For background please see [1]. > > > > Please respond to this message indicating which of the following options > > you prefer by Monday June, 20, 2016 > > > > 1. Use the same key for handshake and application traffic (as in the > > current draft-13) > > > > or > > > > 2. Restore a public content type and different keys > > I prefer (1). > > Dan. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113ac342d986eb053554a107 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I prefer (1)

On Wed, Jun 15, 2016 at 5:51 PM Dan Harkins <dharkins@lounge.org> wrote:

=C2=A0 Hello,

On Mon, June 13, 2016 12:00 pm, Joseph Salowey wrote:
> For background please see [1].
>
> Please respond to this message indicating which of the following optio= ns
> you prefer by Monday June, 20, 2016
>
> 1. Use the same key for handshake and application traffic (as in the > current draft-13)
>
> or
>
> 2. Restore a public content type and different keys

=C2=A0 I prefer (1).

=C2=A0 Dan.


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a113ac342d986eb053554a107-- From nobody Wed Jun 15 12:38:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C13812DB39 for ; Wed, 15 Jun 2016 12:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTAnP7qbmFoX for ; Wed, 15 Jun 2016 12:38:46 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 7883E12DB41 for ; Wed, 15 Jun 2016 12:38:45 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id h190so30142243ith.1 for ; Wed, 15 Jun 2016 12:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=idgYe4y/Lhn2UPBQlltjyhTU9AZ8jdJrBumNc3anRms=; b=vCGU6UqBwZfL/E2qhoIPavl0N0fKlBT+8UXlSKuqb9K+4gOqsgWguGBpTacM7qMlGU h1db256r9kfvR7Md4i3tI/P4Wa36ZfuJ/2XtOgpRnttl/gm85i1QyBxX300cW999gsvh OtRlWjoZSZc2SRGP5G8lnpnJ1t0Cli4AzUGLq9nbL6dKpH1RniXwEOcBcF82nqeql6jT QljpEkMcVQxE8nGmmJa8lXb51U/d1e4xIEHtvFhatCs2KohR5zIIAE5lBl7zv3x1k+sA Wfap7gUpVSIMBvE9FCoE2Ug8TH49LLjlKgyfXYXJV5X+GdsEjFXfwBltpRUNcGzKKOd8 VltA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=idgYe4y/Lhn2UPBQlltjyhTU9AZ8jdJrBumNc3anRms=; b=eDcykO/VWjD2unLOO0hmKGQHus1vIfDWWaKHFzNXARrGTv8swnkTJauFRHWF6HcXMD Vw1BKihziU2zIwstpNIo/Vu493aYlBpHdrBJKONaJiUNDPNCsLlstnFFVe6I/wwpyK8s axkeUeO8L+pZVyr9+VO20kS344gahJ7udRJU7U8Mf/Yrj6ETrQ1d/xl2UzpUosomD7wY wb6lIEvbLDZB1QL5jDn8MC3JTu0ZQC0QA/YIWt8c1Fy0vxenkvYRKsWArY/YZQTwCl82 ruNgazbjGvievijRgWh0Mdijl6tqv6JCPbEcimDgZDRcIMBtXFvG/wR7B+tUd77BsbTq +TSQ== X-Gm-Message-State: ALyK8tIkaP1CqdrscLYQSw6/lPaqX9YPTM+DXg3LxU8wMd80tXgw6zHRTI1ZZC98YdsKRA== X-Received: by 10.36.122.210 with SMTP id a201mr1924995itc.13.1466019524539; Wed, 15 Jun 2016 12:38:44 -0700 (PDT) Received: from stebila-imac.cas.mcmaster.ca (stebila-imac.cas.McMaster.CA. [130.113.68.195]) by smtp.gmail.com with ESMTPSA id g73sm17750035iog.6.2016.06.15.12.38.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Jun 2016 12:38:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Douglas Stebila In-Reply-To: Date: Wed, 15 Jun 2016 15:38:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Joseph Salowey X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Closing on keys used for handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2016 19:38:47 -0000 On Jun 3, 2016, at 17:54, Joseph Salowey wrote: >=20 > Unfortunately, the TLS record framing is not easily compatible with = having multiple keys used simultaneously: because we encrypt the content = type, it is not possible to use it to determine which key to use to = decrypt. We examined a number of proposals which would allow you to = simultaneously have encrypted content types and separate keys, but they = all appear to be nonviable for one reason or another: [...] > =E2=80=A2 Separately encrypting the content type is inefficient = in a number of ways, especially for DTLS (and would need separate = security analysis). This is probably the most viable of the =E2=80=9Ctry = to get both=E2=80=9D designs. I'd also like more information about the reasoning behind saying that = separately encrypting the content type is inefficient. =20 There was some discussion off-list (but not much) about a proposal to = encrypt content type (handshake or application) with a separate key, = then encrypting data with the corresponding key (handshake key or = application key). The content type would be encrypted using = unauthenticated encryption, resulting in a single byte of ciphertext. = The authenticated encryption using the corresponding key would include = the type as associated data to authenticate it. =20 This had a few drawbacks as I remember it:=20 1) requires one additional byte in the communication;=20 2) requires deriving and keeping an extra key (the "content type key") = around; 3) requires additional encryption/decryption 4) composability of the application key would still be lost because of = post-handshake client authentication. In the off-list discussion, Eric had a potential solution to (1). (3) = was unavoidable but in my opinion relatively minimal cost. (4) is true, = but we now have Hugo's results that give a form of restricted = composability that accommodate post-handshake client authentication. =20 There may have been additional discussions that I wasn't around for. I = have heard it suggested that (2) is the particularly problematic aspect = for DTLS, but I do not know enough about DTLS to understand this. Even = if it is problematic for DTLS, if it is not so problematic for TLS, then = why not do it for at least TLS? =20 Douglas= From nobody Wed Jun 15 13:20:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791FE12DB6A for ; Wed, 15 Jun 2016 13:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1-35FNkG4e8 for ; Wed, 15 Jun 2016 13:20:12 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8EC12D121 for ; Wed, 15 Jun 2016 13:20:12 -0700 (PDT) Received: from fifthhorseman.net (unknown [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 922B2F98B; Wed, 15 Jun 2016 16:20:11 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id B5A5221EB9; Wed, 15 Jun 2016 16:20:10 -0400 (EDT) From: Daniel Kahn Gillmor To: Ilari Liusvaara , tls@ietf.org In-Reply-To: <20160615162338.GA10695@LK-Perkele-V2.elisa-laajakaista.fi> References: <1465977655.20266.3.camel@redhat.com> <26741B4E-3C0F-4E0C-AB44-F7DFCCEFED53@gmail.com> <871t3y1s99.fsf@alice.fifthhorseman.net> <20160615162338.GA10695@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Notmuch/0.22+69~gd812194 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 15 Jun 2016 16:20:10 -0400 Message-ID: <878ty6yzk5.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2016 20:20:14 -0000 On Wed 2016-06-15 12:23:38 -0400, Ilari Liusvaara wrote: > On Wed, Jun 15, 2016 at 09:44:18AM -0400, Daniel Kahn Gillmor wrote: >> On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote: >> >> To be clear, we're being asked to trade these things off against each >> other here, but there are other options which were ruled out in the >> prior framing of the question which don't rule either of them out. >> >> In particular, if we're willing to pay the cost of a slightly more >> complex key schedule (and an increased TLS record size), we could have >> "packet header" keys which protect the content-type itself for all >> non-cleartext TLS records. If we do that, these keys might as well also >> be used to protect the TLS record size itself. This would result in an >> opaque data stream (though obviously record size would still leak in >> DTLS, and timing and framing is still likely to leak the record size in >> the lowest-latency TLS applications). > > Does this need to enlarge TLS record size? Why doesn't encrypting the > content-type/length and then authenticating those off main MAC work maybe i'm not understanding your proposal, but if we're encrypting the record length as well, how do you find (and validate) the main MAC without knowing the record length? > I presume problems from header-flipping (tho in TLS that will kill the > connection if you try...) I'm not sure what header-flipping is... > Also, in DTLS, there could be issues switching the encryption on > (but then, looks like DTLS 1.3 has other unsolved problems > currently..) yes, i think that might be the case. --dkg From nobody Wed Jun 15 14:06:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9ED12DBD5 for ; Wed, 15 Jun 2016 14:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZYXdSOK5kiN for ; Wed, 15 Jun 2016 14:06:17 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [80.12.242.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6AE112D965 for ; Wed, 15 Jun 2016 14:06:08 -0700 (PDT) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d67 with ME id 79661t00417Lgi403966Dv; Wed, 15 Jun 2016 23:06:07 +0200 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWVAd2FuYWRvby5mcg== X-ME-Date: Wed, 15 Jun 2016 23:06:07 +0200 X-ME-IP: 92.170.5.52 To: "tls@ietf.org" , uta@ietf.org References: <1465697482.2175.38.camel@16bits.net> <50a50403-554e-e9c9-2053-ecc33fba55ae@trigofacile.com> <1465776350.6588.22.camel@16bits.net> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <1e2b6952-0d05-38a5-c8a1-27563a8af96f@trigofacile.com> Date: Wed, 15 Jun 2016 23:06:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1465776350.6588.22.camel@16bits.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] [Uta] Compression along with TLS in NNTP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2016 21:06:18 -0000 Hi Ãngel, Sorry for the delay in the response. I was asking some input from developers of news clients. >> It implies here that the client will have to know somehow what kinds >> of newsgroups or articles need extra-security. The client will have >> to send the right COMPRESS commands at the right time. > > Yes. Take into account that often only the client will be able to know > if the newsgroup contents are deemed confidential by the user or not. In the news.software.nntp, Michael Bäuerle gave the following answer: "In general I see the problem at layer 8: the user needs to understand what is going on and how to control things with the user interface of the programs. The same thing as with encrypted E-Mail: it's far too easy with most programs to send confidential information as clear text by accident. For security purposes it is likely already too much to expect that the "compression on/off" switch is recognised as security relevant by the users. Therefore I think the best solution for security is to use a separate newsreader (explicitly compiled without compression support) for security relevant tasks." >> Wouldn't it be better that the server also knows somehow what kinds >> of newsgroups or articles need extra-security, and clears the >> compression dictionary even if not explicitly asked by the client? > > Of course, the server MAY flush the compression dictionary more often > than required to satisfy some security properties (assuming that's > supported by the algorithm). OK. >> that could be avoided by another suggestion: if a client wants to >> access both public groups and secret articles, why not open two >> separate NNTP connections (either in parallel or one after the >> other)? These two sessions can be compressed, and there will be no >> leakage. > > You are sending a stronger signal to someone that was watching the > connection, as he will be able to see the two connections. Plus, that > requires more server resources (supporting several connections per > client) and there is an added overhead of STARTTLS + AUTH on the new > connection. For the client wishing to implement this, it may encounter > itself being throttled or limited to 1 connection to the server per IP. I understand that point, and that it is a bad idea in general (stronger signal + more resources with the issue of limitation to 1 connection / IP). >> So as to answer your proposal of ensuring that the contents of >> articles are not compressed together, we could call "COMPRESS DEFLATE >> FLUSH" (or another better optional argument) that asks the server to >> clear the compression dictionary after every response. > > I expect it to have a similar complexity as allowing a complete > algorithm change, while being more limited. What if eg. the user wanted > to authenticate again with a different set of credentials? A user cannot authenticate twice in NNTP (RFC 4643). The AUTHINFO command is no longer available after a successful use. The user needs to open another NNTP connection. Using an NNTP command several times in a row to change a state is not usual. Suggestion from news.software.nntp not adding more complexity: "The simple "compression on/off" switch is very easy to implement and should be sufficient for nearly all non academic scenarios. But maybe the default setting for the switch should be defined as "off", because this is the more secure option. Possible words instead of the current: | Implementations MUST support a configuration where compression can be | easily disabled. --- Implementations SHOULD use a default configuration with disabled compression and MUST support an option to easily enable compression [either with global scope or server/connection based]. --- This will ensure that e.g. a new version of a newsreader with support for compression will not enable it automatically (possibly without knowledge of a user who have not read the changelog)." I suggest to also say, like your proposal, that news servers MAY have a global or connection based configuration parameter permitting to enforce more confidentiality on specific newsgroups (notably by ensuring for these newsgroups that the contents of two secret articles are not compressed together). The server will then clear the compression dictionary either after selecting these newsgroups or before sending any article posted to these newsgroups. Wouldn't these additions: - default configuration of disabled compression, - ideas to ensure protection is maximal for those wishing to implement a newsgroups based compression, - clarification that the main problem is that public data and confidential data are compressed together (and not that encryption and compression are used together), satisfy the needs of security? We believe it would work better than complexifying the simple COMPRESS command, and that it no longer introduces potential security issues in the default configuration (whereas the previous version did). -- Julien ÉLIE « A man inserted an 'ad' in the classifieds: "Wife wanted". Next day he received a hundred letters. They all said the same thing: "You can have mine." » From nobody Wed Jun 15 20:04:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D10E12DC96 for ; Wed, 15 Jun 2016 20:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WknSiiQMrma for ; Wed, 15 Jun 2016 20:04:43 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002: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 BB81012DC95 for ; Wed, 15 Jun 2016 20:04:40 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id z186so31677958ywd.2 for ; Wed, 15 Jun 2016 20:04:40 -0700 (PDT) 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-transfer-encoding:message-id; bh=0dXirW2c5x851qwBiMdmPd95kzBskCLCCinaDw9f/rI=; b=t6OjUFh0ooTQliTkfhM+HJNea0S91gVqEmfvH1g5Dut8brZntXr6omdQG3yQ3zx7zA cK0eBA67l+i96J1bMlSb+2xLOLKmnCMPZEEkuzkhvMQaKmTDK3FNslcA/s7fjmjwkQVv tHtpevzEmdqKgRJh1W8OAr4I4lVd8jNThz4d/qfwxy88K5gssGER4XQK/GiOkUjFciNV vawa8dJihwF/8EjSEF4eDoHrzzUhoK2oe2oX13uc9Gl2PkJUXBm0Yx2ZP32H1Yc4vDMV MazjWfWKb6PeKxyRsZraK+s58pkZzq3kgGu7RVRIzAKJLECtcHY+EpHPV1+QcTcai/61 CWDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=0dXirW2c5x851qwBiMdmPd95kzBskCLCCinaDw9f/rI=; b=d5P2N0/pIikD+wyjM+gDyp5jGbXrg6Nqc8S/60qbTt5hre/BJ0EHXW95BHGKvGajid /Xmm/RXwtlwFvTwxwnj2AwcNimG3D2DH8Y8rsDM37Wdwv73gyjpBep+uTP6yTPekTZEg bC3xfjIv4L8zEv06NL61TYMOftb0R0L7BFqPkxzmdOM0H+DsUmMsDE/MX8WepbMs5E1B 4pEoGo3uHV9TAn73G/4RmwLvAGooCxHxwu0fBRpncB53BZlK+Z3e4NihrFSZrZr1692x odnv9fJnJIVJ/edTtRFRzGLSroIwnSGH/aUlzJdsOs3T/8HnCfHnrXDI8OKmShggNdVY hRsQ== X-Gm-Message-State: ALyK8tKC52CwYGOdmxJzGl0ohLt7nfDwEcDxDnx6auwm7dOt6Pvp0fpeOmMTjmWPMV6vYw== X-Received: by 10.37.80.132 with SMTP id e126mr1254323ybb.2.1466046279909; Wed, 15 Jun 2016 20:04:39 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id g193sm10631227ywb.13.2016.06.15.20.04.39 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 15 Jun 2016 20:04:39 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 15 Jun 2016 23:04:37 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <8760tc3kd0.fsf@alice.fifthhorseman.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201606152304.38016.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 16 Jun 2016 03:04:45 -0000 On Tuesday, June 14, 2016 04:37:09 am Martin Thomson wrote: > On 13 June 2016 at 21:27, Daniel Kahn Gillmor wrote: > > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: > > > 1. Use the same key for handshake and application traffic (as in the > > > current draft-13) > > > > > > or > > > > > > 2. Restore a public content type and different keys > > > > Given this choice, i prefer (1). > > +1 > > However... > > I confess that I still haven't properly internalized the objection > from the cryptographers, and that means that I could probably live > with a public content type if more convincing evidence for the value > of 2 could be produced. +1 From nobody Wed Jun 15 23:13:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E3212D193 for ; Wed, 15 Jun 2016 23:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuM5pQ0qHUSG for ; Wed, 15 Jun 2016 23:13:36 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A920712B057 for ; Wed, 15 Jun 2016 23:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1466057615; x=1497593615; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yuCMY9hczsu80Gzj++z9W/k2Yy0pQjyH7USF2ZOcCzw=; b=oIMjhBQH+MT5cByUa57iEilP8Haa6YdhNKWGd0bI0SO+M3MB5ZLyqk9L AmQqWhijzFzfDlO7pNKEDqrN3ZUWoVejv2NMikrXunw2El+kWPJfK166Z PsgXIqfz6Vc+NX6SEuhFZ/bkXgMK85gw10D3bGjQVga4vM+8uF70m6YVY W/xKfPCuupkYNprhE/G+UMQxe7tINwCRvKE+QX2gQP6sJri0NtkxMoZu7 Tc/SdrgyJjHOVSUxkG4lhfK9q3d/o5ZZsyCaYsmjsb42IYjXPa512ZLK+ exMxDxSH9XjKRr+D2sZG4xKZecCzeqUNaQ749xFikcB75YSXaYtksQyag A==; X-IronPort-AV: E=Sophos;i="5.26,478,1459771200"; d="scan'208";a="91692707" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 16 Jun 2016 18:13:31 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Thu, 16 Jun 2016 18:13:31 +1200 From: Peter Gutmann To: Hubert Kario Thread-Topic: [TLS] Adoption of TLS-LTS Thread-Index: AdG/9CVqy8MYXur6TqWx/88FbT3L7gBWWRwAABuaKxIABSL9gAD3FFPHAAVV+IAAdPsM5w== Date: Thu, 16 Jun 2016 06:13:31 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CA2A5C@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C9CA49@uxcn10-5.UoA.auckland.ac.nz> <22902566.AuEvmjhU12@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4CA0C94@uxcn10-5.UoA.auckland.ac.nz>, <1843800.YErRuY4C85@pintsize.usersys.redhat.com> In-Reply-To: <1843800.YErRuY4C85@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: [10.6.2.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] Adoption of TLS-LTS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 16 Jun 2016 06:13:40 -0000 Hubert Kario writes:=0A= >On Monday 13 June 2016 19:51:42 Peter Gutmann wrote:=0A= >> Hubert Kario writes:=0A= >> >to be pedantic, the RFC describes itself "a profile" while in reality= =0A= >> >it modifies the protocol in a way that will make it incompatible=0A= >> >with "vanilla" TLS 1.2 implementations=0A= >> =0A= >> Oh, right. Well that's easily fixed, I used "profile" because I=0A= >> couldn't think of a better term, the best I could come up with is=0A= >> "plan", but it's not really a plan either. If people think "plan" is=0A= >> better than "profile", and it deals with Russ' objection, I'll change=0A= >> it to that. Alternatively, if you can think of a better term than=0A= >> "plan", let me know (or forever hold your peace :-).=0A= >=0A= >"TLS refitting for Long Term Support"=0A= >=0A= >"Adaptation of TLS for Long Term Support"=0A= >=0A= >"LTS revision of TLS"=0A= >=0A= >"LTS addendum to TLS 1.2" (amendment?)=0A= =0A= So after some discussion with some of the people who'll be using this, we c= ame=0A= up with:=0A= =0A= TLS 1.2 Update for Long-term Support=0A= =0A= among other suggestions, but that seemed to be the best one. Other options= =0A= were things like "modernisation" or "improvement" (and one of them suggeste= d=0A= "adaptation" as well), but I think "update" says it best. "Revision" is mo= re=0A= or less the same as "Update", so I guess either would fit, but I'm leaning= =0A= more towards "Update".=0A= =0A= If no-one has any other suggestions I'll post an updated draft, I'm just=0A= waiting for permission to include the details of the interop test server th= at=0A= people can run their clients against.=0A= =0A= Peter.=0A= From nobody Thu Jun 16 02:51:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C9512D096 for ; Thu, 16 Jun 2016 02:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOQw-UVmz6AI for ; Thu, 16 Jun 2016 02:51:17 -0700 (PDT) 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 A3E3B12B071 for ; Thu, 16 Jun 2016 02:51:16 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id m124so61169685wme.1 for ; Thu, 16 Jun 2016 02:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:from:date:message-id:subject:to; bh=qQQyRLlN0mihJK8xdXbaVNB7fI5wzDyVBVG8q3RRAoY=; b=jWLQ9X8F1sIdwrNxvpSLr7QIysyi/V5lJetWN9KyzlRS2b15iE11dd9Fbtq1cbRWI5 JyA0T92SIHxAMEjV83Z0tjScHPDYuddmH9tMUMuizym1K01OABFoea/9lEd1K0bWZHbh vWe20129JcKrQFS16p9WLufe3jxYhWb7KpvEXqLY44PoX06V0Zlom6ZcxzEp0Xt+ZN6x mqt8F8lMS4dtlqHYCpvruRU1UfzHId90MU0yrgzW6ei14+t9JUW9P90FY3W6X1L+w9Hg uWZjlBcGsuU6FNh73M7c3ELl1QmgVgffiULY67a8mp3j96ZDf2lFYPhoCgzIVy3kRqYt SX5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:sender:from:date :message-id:subject:to; bh=qQQyRLlN0mihJK8xdXbaVNB7fI5wzDyVBVG8q3RRAoY=; b=BZxTxGg3d3XQ6nWXcse1BrEFQhZF1d4WihIIetBK2BzNoPgmmJLHVYqOWYckghrUo+ u2grtRokcXahJR4Ubeh3KR3vnVxdvp0XWZqoTW8/TKXQD2VW0S7zjg88TEoEzjjnsEb/ kHt1j8hJZvfdcltuhqQDKyJVCyg74HNLR51ZXIPfyUpoJ4ZmcDpDHNJE3kWi3ydm5hoe 2WsQkvtHNudnX3Ka02lnwLl+OQ2CqoH6nZkr1pUgxhEfvy/VkWOATeQkfWPHZSVoKlef PbatlvhqnMUz8alke2enRK3Xx7VptyPsEta3wVJE3d0MGi8wixlF+S4Ad9SkvR4SQlMG A/rg== X-Gm-Message-State: ALyK8tIumQlXT21CUsSqt6LVJQ6cTUpAR2WXA8kePo0S9tKshogL/rr4hp9tJS2KjlmEIo+OKCUizfMYwLUjCQ== X-Received: by 10.28.41.65 with SMTP id p62mr14043125wmp.15.1466070675109; Thu, 16 Jun 2016 02:51:15 -0700 (PDT) MIME-Version: 1.0 Sender: robert.cragie@gmail.com Received: by 10.194.223.106 with HTTP; Thu, 16 Jun 2016 02:51:14 -0700 (PDT) From: Robert Cragie Date: Thu, 16 Jun 2016 10:51:14 +0100 X-Google-Sender-Auth: -di5ZNdLta_Cj2sr-MbpX_QygAI Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a114e35b0ce46670535622db8 Archived-At: Subject: [TLS] Comments on TLS-ECJ-PAKE draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: robert.cragie@gridmerge.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, 16 Jun 2016 09:51:19 -0000 --001a114e35b0ce46670535622db8 Content-Type: text/plain; charset=UTF-8 I would like to ask the working group for comments on the TLS-ECJ-PAKE draft: https://tools.ietf.org/html/draft-cragie-tls-ecjpake-00 Some brief notes: * This intended status is informational. * The draft is based on TLS/DTLS 1.2 as the Thread group required basis on existing RFCs wherever possible. For that reason and due to the WGs focus on TLS 1.3, I have understood from the chairs that it would not have received a great deal of attention from the WG, hence the intended status of informational. * The draft reflects the current use of the TLS_ECJPAKE_WITH_AES_128_CCM_8 cipher suite in Thread (http://threadgroup.org/). * There is an experimental implementation in mbed TLS ( https://github.com/ARMmbed/mbedtls) * The Thread group would like to get IANA assignments for 4 cipher suite values and one ExtensionType value as soon as possible. * There are at least four independent implementations, which have been used in interop. testing over the last 18 months. * The security considerations recommend restriction of the use of this cipher suite to Thread and similar applications and recommends it should not be used with web browsers and servers (mainly due to the long discussions regarding the use of PAKEs on this and other mailing lists). Robert --001a114e35b0ce46670535622db8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would like to ask the working group for comments on= the TLS-ECJ-PAKE draft:


Some brief notes:

* This intended status is informational.
* T= he draft is based on TLS/DTLS 1.2 as the Thread group required basis on exi= sting RFCs wherever possible. For that reason and due to the WGs focus on T= LS 1.3, I have understood from the chairs that it would not have received a= great deal of attention from the WG, hence the intended status of informat= ional.
* The draft reflects the current use of the TLS_ECJPAKE_WI= TH_AES_128_CCM_8 cipher suite in Thread (http://threadgroup.org/).
* There is an experimental implem= entation in mbed TLS (https:= //github.com/ARMmbed/mbedtls)
* The Thread group would like t= o get IANA assignments for 4 cipher suite values and one ExtensionType valu= e as soon as possible.
* There are at least four independent impl= ementations, which have been used in interop. testing over the last 18 mont= hs.
* The security considerations recommend restriction of the us= e of this cipher suite to Thread and similar applications and recommends it= should not be used with web browsers and servers (mainly due to the long d= iscussions regarding the use of PAKEs on this and other mailing lists).

Robert
--001a114e35b0ce46670535622db8-- From nobody Thu Jun 16 08:26:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E35212D88B for ; Thu, 16 Jun 2016 08:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.328 X-Spam-Level: X-Spam-Status: No, score=-8.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75YXg9R7BBnP for ; Thu, 16 Jun 2016 08:26:29 -0700 (PDT) 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 91A1912D7BC for ; Thu, 16 Jun 2016 08:26:29 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 105CDC003555; Thu, 16 Jun 2016 15:26:29 +0000 (UTC) Received: from pintsize.usersys.redhat.com ([10.34.251.45]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5GFQRMO007480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2016 11:26:28 -0400 From: Hubert Kario To: tls@ietf.org Date: Thu, 16 Jun 2016 17:26:14 +0200 Message-ID: <1853340.Xg5UvgGrF6@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.12-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <871t3y1s99.fsf@alice.fifthhorseman.net> References: <26741B4E-3C0F-4E0C-AB44-F7DFCCEFED53@gmail.com> <871t3y1s99.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4291365.GTF4zIuSHH"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 16 Jun 2016 15:26:29 +0000 (UTC) Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 16 Jun 2016 15:26:30 -0000 --nextPart4291365.GTF4zIuSHH Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 15 June 2016 09:44:18 Daniel Kahn Gillmor wrote: > On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote: > > I disagree that this is a low level crypto decision, or at least > > that this is mainly so. > >=20 > > There is the question of whether using the same key for application= > > data and handshake is harmful. That question is mainly low level > > crypto and could be asked of CFRG. > >=20 > > There is the other question of whether exposing the fact that there= > > are handshake messages and when they occur is harmful. That is > > security-related, but not at all related to crypto. > >=20 > > Weighing these two potential harms against each other and coming to= > > a decision is entirely an engineering issue, and we should not > > offload that to CFRG. > To be clear, we're being asked to trade these things off against each= > other here, but there are other options which were ruled out in the > prior framing of the question which don't rule either of them out. >=20 > In particular, if we're willing to pay the cost of a slightly more > complex key schedule (and an increased TLS record size), we could hav= e > "packet header" keys which protect the content-type itself for all > non-cleartext TLS records. If we do that, these keys might as well > also be used to protect the TLS record size itself. This would > result in an opaque data stream (though obviously record size would > still leak in DTLS, and timing and framing is still likely to leak > the record size in the lowest-latency TLS applications). wasn't that rejected because it breaks boxes that do passive monitoring= =20 of connections? (and so expect TLS packets on specific ports, killing=20= connection if they don't look like TLS packets) =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 --nextPart4291365.GTF4zIuSHH 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 iQIcBAABCgAGBQJXYsUWAAoJEJKo0bgB0vX1CKQQAKFawWKkNqSv4vwiN4FxeVrY +fpRWe+TEh/Z8pRQuWX9l+XGTGLjXz2Ns54Dfgk5o20PAkj5+HBxei7Cw9Fk2Esd XKP0h2nquClkUBmexWYYdDBvMGtA6iyP9kYk/OXR8DLP0CQmcwSWpq01u+CH6eH0 OwRgPJTxwRPsmbLf9r+4NVhpYtfrD+ORx5zuris34xDXgtAhx45T7L/9NUMiNai7 EPnkVYPLoulMhA4N3t0/ncb305udTH5wHSS/WWqNeaWxg29n+furphkURxTYuDqU LPE1n24vGhcoIdM6Sp24yKIH9DYnN1Z6wpdhPtUn3DVicEycSTbkB8cAOvORo2n3 YG6KFrxbQFsWdFg/PqtxgDB5/7Ib8aZe0W7+P8SSunD4/LhNvgG69D9JrThH/LaO PzWmPkNvM+iYZVYR0YrUzABe2RQc6XgPbfWSLaouf+DyNiuHmDAWkfLTtWzWNa6I vV/q8V0IF5NwM6Gwq+NeU8/il/wJ0lCau/R/WrGADkCIO6Ctqpl2mek6VYSdEOUN xI2gFy3vKHUrYL/PhNjX4j2C2BO2HAi6SST2HaSfjIrGLN53kB7Oi4dLBPNBPmU1 W/xKtfxI8FwJ07BTXhk3umhtafvaPR5W58Pmnm9WxmwhffH+0AWmgSYguSRvaANI Hk5Fk3ICQ9WmTXWxf/wS =sgWo -----END PGP SIGNATURE----- --nextPart4291365.GTF4zIuSHH-- From nobody Thu Jun 16 09:13:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D4D12D951 for ; Thu, 16 Jun 2016 09:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OgEX_n4qOVM for ; Thu, 16 Jun 2016 09:13:32 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABB812D8EE for ; Thu, 16 Jun 2016 09:13:30 -0700 (PDT) Received: from fifthhorseman.net (unknown [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 78BC6F98B; Thu, 16 Jun 2016 12:13:28 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 297D61FFC0; Thu, 16 Jun 2016 12:13:28 -0400 (EDT) From: Daniel Kahn Gillmor To: Hubert Kario , tls@ietf.org In-Reply-To: <1853340.Xg5UvgGrF6@pintsize.usersys.redhat.com> References: <26741B4E-3C0F-4E0C-AB44-F7DFCCEFED53@gmail.com> <871t3y1s99.fsf@alice.fifthhorseman.net> <1853340.Xg5UvgGrF6@pintsize.usersys.redhat.com> User-Agent: Notmuch/0.22+69~gd812194 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 16 Jun 2016 12:13:28 -0400 Message-ID: <87mvmlw1qv.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 16 Jun 2016 16:13:33 -0000 On Thu 2016-06-16 11:26:14 -0400, Hubert Kario wrote: > wasn't that rejected because it breaks boxes that do passive monitoring > of connections? (and so expect TLS packets on specific ports, killing > connection if they don't look like TLS packets) We're talking about the possibility of changing the TLS record framing anyway, which would kill the simplest of those boxes. One theory is if you're going to make such a break, you might as well pull the band aid off in one fell swoop. --dkg From nobody Thu Jun 16 11:05:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEACF12DA6E for ; Thu, 16 Jun 2016 11:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGVjHkDUA5rh for ; Thu, 16 Jun 2016 11:05:20 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id BF3EA12DA57 for ; Thu, 16 Jun 2016 11:05:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id BDD4316A0 for ; Thu, 16 Jun 2016 21:05:18 +0300 (EEST) 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 IOS50mZ7fT9b for ; Thu, 16 Jun 2016 21:05:18 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-224-2.bb.dnainternet.fi [87.100.224.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 74A592313 for ; Thu, 16 Jun 2016 21:05:18 +0300 (EEST) Date: Thu, 16 Jun 2016 21:05:15 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160616180515.GA12200@LK-Perkele-V2.elisa-laajakaista.fi> References: <26741B4E-3C0F-4E0C-AB44-F7DFCCEFED53@gmail.com> <871t3y1s99.fsf@alice.fifthhorseman.net> <1853340.Xg5UvgGrF6@pintsize.usersys.redhat.com> <87mvmlw1qv.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87mvmlw1qv.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 16 Jun 2016 18:05:23 -0000 On Thu, Jun 16, 2016 at 12:13:28PM -0400, Daniel Kahn Gillmor wrote: > On Thu 2016-06-16 11:26:14 -0400, Hubert Kario wrote: > > wasn't that rejected because it breaks boxes that do passive monitoring > > of connections? (and so expect TLS packets on specific ports, killing > > connection if they don't look like TLS packets) > > We're talking about the possibility of changing the TLS record framing > anyway, which would kill the simplest of those boxes. One theory is if > you're going to make such a break, you might as well pull the band aid > off in one fell swoop. One scheme with minimum overhead (3 bytes + crypto tag + padding) to that doesn't do record hiding, is not compatible with multiple keys nor SRTP mux: - Bit 7 of first byte: 0 => normal TLS 1.0-style 5 byte header. 1 => 2 bytes, low 15 bits are length of encrypted record. And then do draft-13-style padding inside encrypted envelope. If one wants to do record hiding and MAC the headers, one would presumably want 64-bit tags due to space usage. Unfortunately, algebraic MACs tend to be rather weak at 64-bits (forgeries tend to give up lots of information about the key) and non-algebraic ones (based on hashes) tend to be a bit slow. -Ilari From nobody Fri Jun 17 09:46:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A7012D85F for ; Fri, 17 Jun 2016 09:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuuSXAji8_rk for ; Fri, 17 Jun 2016 09:46:03 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0077.outbound.protection.outlook.com [104.47.1.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86C9912D85E for ; Fri, 17 Jun 2016 09:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=owmHEXrSwLDg78lkgy++t7kaalrAMfZkN64xHTvYjFg=; b=eW8Auxdcc2WEL+OCy1rpnCAJXR/37rJQ/8oadIW47H9j5BXmpwWqySHWMs9S4kwO5Y47mSvEjNES69mhIDsga2jsDf6MHNecZzXs+jj5Rm6HDuHT8jSh79w1Ma787ELAylbS9+XNqgddIjmitZSoLjVSiPW5PeyyaH8a2j2hgm4= Received: from AM4PR03MB1811.eurprd03.prod.outlook.com (10.167.88.147) by AM4PR03MB1809.eurprd03.prod.outlook.com (10.167.88.145) with Microsoft SMTP Server (TLS) id 15.1.517.8; Fri, 17 Jun 2016 16:46:00 +0000 Received: from AM4PR03MB1811.eurprd03.prod.outlook.com ([10.167.88.147]) by AM4PR03MB1811.eurprd03.prod.outlook.com ([10.167.88.147]) with mapi id 15.01.0517.014; Fri, 17 Jun 2016 16:45:59 +0000 From: "Paterson, Kenny" To: Ilari Liusvaara , "tls@ietf.org" Thread-Topic: [TLS] Consensus call for keys used in handshake and data messages Thread-Index: AQHRyLe6z4Pt+m6ycEKUe6eKsuHzbw== Date: Fri, 17 Jun 2016 16:45:59 +0000 Message-ID: References: <1465977655.20266.3.camel@redhat.com> <26741B4E-3C0F-4E0C-AB44-F7DFCCEFED53@gmail.com> <871t3y1s99.fsf@alice.fifthhorseman.net> <20160615162338.GA10695@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160615162338.GA10695@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [134.219.148.47] x-ms-office365-filtering-correlation-id: 5c63ddeb-7249-4129-0966-08d396cedcb3 x-microsoft-exchange-diagnostics: 1; AM4PR03MB1809; 6:Xq3YUxQtM1Rw+k3QOTbvLbBAHc9nBx/Fp84vjCW2R9IL4iWbV+Wa8V3h1Fp8G+/lik6h27D0btb66SbKUWA5I/Tn5dxpMSzhA4xSR1AWf/E2amxz0Op4chnRo8P4o0EEbSTnAAAjveevUEsjx6IpbhOKQ20BAVqTFIBrygEBjxw4KGiMybK78qPgVR2O4TCQzJ3rCAHR/jgbIEkr4hMYd2VcX4uAv6/9M94WVzPjwEQfkL4O6fBiooCtRAMHJOf7inFXXuTERZx2o7l2D7gd4knDiy8t7NaVOPIKKQAaNdc=; 5:9cwiWG3a7fSofkR8S6K3AHakRYV6AufmdLTSk8CNDthiegr+tk1DF1vABGpRume8eJEMWf3Wsa7aTF677YoiXsOUCyR3XdnQa+KVka0gXTF2VVNlftYeCafRg4XrleZSN3alt/1qWXF9p4T+5oXSTA==; 24:zN3panra872i5Avja4b0N6TM+5W95McSKe63jFeidMtkaio6toNixzCWSaaaKBsiATv2QdmT8uvZRP7dh5MuHplrxI2HxncGvN/hMSDcSyE=; 7:vzLxdIFtQtrw/gATnC5tFeASp+GaRZzFNW+xzKTvtpBKf62LS8PLJa0juASbKvA/XML5txR/3fxWYYQGdWu04wyYgfONUtN1E44GBv5tIEquoA04bc09g8fB1f0nbjs1U2raMC1ONuRop+BdnlOQ4r+NGrzIUMxUjx9nkVeAhEILqGOMDXFnY6hntWegQAe7JVfCbFW+vNLP/YR9Ro0TCw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR03MB1809; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AM4PR03MB1809; BCL:0; PCL:0; RULEID:; SRVR:AM4PR03MB1809; x-forefront-prvs: 09760A0505 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(24454002)(377424004)(189002)(86362001)(5004730100002)(36756003)(66066001)(6116002)(102836003)(3846002)(3660700001)(3280700002)(586003)(93886004)(68736007)(83506001)(92566002)(2501003)(189998001)(5002640100001)(19580395003)(4001350100001)(19580405001)(122556002)(97736004)(107886002)(5001770100001)(105586002)(54356999)(76176999)(15650500001)(50986999)(10400500002)(74482002)(15975445007)(2900100001)(106356001)(106116001)(2950100001)(87936001)(2906002)(101416001)(8936002)(8676002)(77096005)(81156014)(81166006)(7846002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR03MB1809; H:AM4PR03MB1811.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <1F09C967808652428D9DE322D89AC861@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2016 16:45:59.8861 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1809 Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 17 Jun 2016 16:46:05 -0000 SGkgSWxhcmksDQoNCk9uIDE1LzA2LzIwMTYgMTc6MjMsICJUTFMgb24gYmVoYWxmIG9mIElsYXJp IExpdXN2YWFyYSINCjx0bHMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaWxhcmlsaXVz dmFhcmFAd2VsaG8uY29tPiB3cm90ZToNCg0KPk9uIFdlZCwgSnVuIDE1LCAyMDE2IGF0IDA5OjQ0 OjE4QU0gLTA0MDAsIERhbmllbCBLYWhuIEdpbGxtb3Igd3JvdGU6DQo+PiBPbiBXZWQgMjAxNi0w Ni0xNSAwNDo0NDo1OSAtMDQwMCwgWW9hdiBOaXIgd3JvdGU6DQo+PiANCj4+IFRvIGJlIGNsZWFy LCB3ZSdyZSBiZWluZyBhc2tlZCB0byB0cmFkZSB0aGVzZSB0aGluZ3Mgb2ZmIGFnYWluc3QgZWFj aA0KPj4gb3RoZXIgaGVyZSwgYnV0IHRoZXJlIGFyZSBvdGhlciBvcHRpb25zIHdoaWNoIHdlcmUg cnVsZWQgb3V0IGluIHRoZQ0KPj4gcHJpb3IgZnJhbWluZyBvZiB0aGUgcXVlc3Rpb24gd2hpY2gg ZG9uJ3QgcnVsZSBlaXRoZXIgb2YgdGhlbSBvdXQuDQo+PiANCj4+IEluIHBhcnRpY3VsYXIsIGlm IHdlJ3JlIHdpbGxpbmcgdG8gcGF5IHRoZSBjb3N0IG9mIGEgc2xpZ2h0bHkgbW9yZQ0KPj4gY29t cGxleCBrZXkgc2NoZWR1bGUgKGFuZCBhbiBpbmNyZWFzZWQgVExTIHJlY29yZCBzaXplKSwgd2Ug Y291bGQgaGF2ZQ0KPj4gInBhY2tldCBoZWFkZXIiIGtleXMgd2hpY2ggcHJvdGVjdCB0aGUgY29u dGVudC10eXBlIGl0c2VsZiBmb3IgYWxsDQo+PiBub24tY2xlYXJ0ZXh0IFRMUyByZWNvcmRzLiAg SWYgd2UgZG8gdGhhdCwgdGhlc2Uga2V5cyBtaWdodCBhcyB3ZWxsIGFsc28NCj4+IGJlIHVzZWQg dG8gcHJvdGVjdCB0aGUgVExTIHJlY29yZCBzaXplIGl0c2VsZi4gIFRoaXMgd291bGQgcmVzdWx0 IGluIGFuDQo+PiBvcGFxdWUgZGF0YSBzdHJlYW0gKHRob3VnaCBvYnZpb3VzbHkgcmVjb3JkIHNp emUgd291bGQgc3RpbGwgbGVhayBpbg0KPj4gRFRMUywgYW5kIHRpbWluZyBhbmQgZnJhbWluZyBp cyBzdGlsbCBsaWtlbHkgdG8gbGVhayB0aGUgcmVjb3JkIHNpemUgaW4NCj4+IHRoZSBsb3dlc3Qt bGF0ZW5jeSBUTFMgYXBwbGljYXRpb25zKS4NCj4NCj5Eb2VzIHRoaXMgbmVlZCB0byBlbmxhcmdl IFRMUyByZWNvcmQgc2l6ZT8gV2h5IGRvZXNuJ3QgZW5jcnlwdGluZyB0aGUNCj5jb250ZW50LXR5 cGUvbGVuZ3RoIGFuZCB0aGVuIGF1dGhlbnRpY2F0aW5nIHRob3NlIG9mZiBtYWluIE1BQyB3b3Jr DQo+KHRoYXQncyBob3cgU1NIIHdpdGggQ0hBQ0hBMjAtUE9MWTEzMDUgZG9lcyB0aGluZ3MpPyBJ IHByZXN1bWUNCj5wcm9ibGVtcyBmcm9tIGhlYWRlci1mbGlwcGluZyAodGhvIGluIFRMUyB0aGF0 IHdpbGwga2lsbCB0aGUNCj5jb25uZWN0aW9uIGlmIHlvdSB0cnkuLi4pDQoNClllcywgdGhpcyBj YW4gYmUgbWFkZSB0byB3b3JrIGluIHRoZSBzdHlsZSBhZG9wdGVkIGZvciBDaGFDaGEyMC1Qb2x5 MTMwNQ0KaW4gU1NILiANCg0KSG93ZXZlciwgYmVjYXVzZSB0aGUgcmVjb3JkIGxlbmd0aCBpcyBu b3cgZGV0ZXJtaW5lZCBieSBkYXRhIHRoYXQgaXMNCmVuY3J5cHRlZCwgYW5kIHlvdSBuZWVkIHRv IGtub3cgaXRzIHZhbHVlIGluIG9yZGVyIHRvICJyZWNlaXZlIiBlbm91Z2gNCmJ5dGVzIHRvIGhh dmUgb2J0YWluZWQgdGhlIHJlY29yZCBNQUMgd2hpY2ggY29tZXMgYXQgdGhlIGVuZCBvZiB0aGUN CnJlY29yZCwgYW5kIGJlY2F1c2UgdGhlIHJlY29yZCBNQUMgY2FuJ3Qgbm93IGJlIGNoZWNrZWQg YmVmb3JlIHlvdSBtYWtlDQp1c2Ugb2YgdGhlIGxlbmd0aCBmaWVsZCAuLi4uIHlvdSBuZWVkIHRv IGJlIGEgYml0IGNhcmVmdWwuDQoNCkJ1dCBpdCBjYW4gYmUgcHJvdmVkIHNlY3VyZSB3aGVuIHVz aW5nIGNlcnRhaW4gQUVBRCBzY2hlbWVzIGFzIHRoZSBiYXNpcywNCmFuZCBpbiBhIHN1aXRhYmxl IHNlY3VyaXR5IG1vZGVsIHRoYXQgYWxsb3dzIGZvciBkZWNyeXB0aW9uIGluIHBhcnQNCmRlcGVu ZGluZyBvbiBkYXRhIHRoYXQgd2FzIGFjdGVkIG9uIGJlZm9yZSBpdCB3YXMgdW5hdXRoZW50aWNh dGVkIGFuZCBmb3INCmRlbGl2ZXJ5IG9mIHJlY29yZHMgaW4gYSBmcmFnbWVudGVkIGZhc2hpb24u IEp1c3QgZG9uJ3QgdXNlIENCQyBtb2RlIGZvcg0KdGhlIGVuY3J5cHRpb24gOi0pICAoQSBtb3Jl IHNlcmlvdXMgcG9pbnQ6IHRoaXMga2luZCBvZiB0aGluZyB3b3VsZCBub3QgYmUNCnNlY3VyZSB1 c2luZyBhIGdlbmVyaWMgRXRNLXN0eWxlIEFFQUQgc2NoZW1lIGFzIHRoZSBidWlsZGluZyBibG9j ay4pDQoNCkluIGZhY3QsIGlmIHlvdSdyZSBjYXJlZnVsIGVub3VnaCB3aXRoIHRoZSBhbmFseXNp cywgeW91IGNhbiBpbXByb3ZlIGEgYml0DQpvbiB0aGUgQ2hhQ2hhMjAtUG9seTEzMDUgY29uc3Ry dWN0aW9uIGluIFNTSDogaXQgY3VycmVudGx5IHVzZXMgYSA2NC1ieXRlDQprZXksIHdpdGggMzIg Ynl0ZXMgYmVpbmcgdXNlZCB0byBjcmVhdGUgb25lIENoYUNoYTIwIGNvbnRleHQgZm9yDQplbmNy eXB0aW5nIHRoZSBsZW5ndGggZmllbGQgYW5kIGFub3RoZXIgMzIgYnl0ZXMgYmVpbmcgdXNlZCB0 byBjcmVhdGUgYQ0Kc2Vjb25kIENoYUNoYTIwIGNvbnRleHQgZm9yIGVuY3J5cHRpbmcgdGhlIHJl c3QuIFRoaXMgaXMgbm90IG5lY2Vzc2FyeSBpZg0KeW91IGNvbnN0cnVjdCB0aGUgQ2hhQ2hhMjAg bm9uY2VzL0lWcyBpbiBhIHNsaWdodGx5IGRpZmZlcmVudCB3YXkgLSBhDQpzaW5nbGUgQ2hhQ2hh MjAgY29udGV4dCBzdWZmaWNlcy4gVGhlIHNhbWUgb3VnaHQgdG8gYmUgdHJ1ZSBpbiB0aGUNCnNs aWdodGx5IGRpZmZlcmVudCBUTFMgc2V0dGluZywgYW5kIGFsc28gZm9yIGFuIEFFUy1HQ00tYmFz ZWQgY29uc3RydWN0aW9uLg0KDQpIYXBweSB0byBmb2xsb3ctdXAgd2l0aCBkaXNjdXNzaW9uIG9m IG1vcmUgZGV0YWlscyBpZiBwZW9wbGUgc2VyaW91c2x5DQp3YW50IHRvIGNvbnNpZGVyIHRoaXMg a2luZCBvZiBjb25zdHJ1Y3Rpb24gZm9yIFRMUyAxLjMuIEl0J3Mgbm90IHdoYXQncw0KY3VycmVu dGx5IG9uIHRoZSB0YWJsZSwgYnV0IG1heWJlIGl0IHNob3VsZCBiZS4uLg0KDQpDaGVlcnMNCg0K S2VubnkgDQoNCj4NCj5BbHNvLCBpbiBEVExTLCB0aGVyZSBjb3VsZCBiZSBpc3N1ZXMgc3dpdGNo aW5nIHRoZSBlbmNyeXB0aW9uIG9uDQo+KGJ1dCB0aGVuLCBsb29rcyBsaWtlIERUTFMgMS4zIGhh cyBvdGhlciB1bnNvbHZlZCBwcm9ibGVtcw0KPmN1cnJlbnRseS4uKQ0KPg0KPg0KPi1JbGFyaQ0K Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ VExTIG1haWxpbmcgbGlzdA0KPlRMU0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdGxzDQoNCg== From nobody Fri Jun 17 10:08:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5823912D7E5 for ; Fri, 17 Jun 2016 10:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bd752NCIbhCU for ; Fri, 17 Jun 2016 10:08:05 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0604.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::604]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C23F12D7CB for ; Fri, 17 Jun 2016 10:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YMCiEeXtoWt9W/cck8LoNDEgksSJ8AQMtDXU7RFYcqo=; b=M68Wf9alzoWCXQId2bEklvHJ2lT1kp3wXO7csBcq1kS3wRqEnmIpSRHJ0pqmn75GgH32q4vEgYIo47r8HDIspUUMuIvsIvW3AGVgMfAf+eo0y3LPzTHuKTqpommv1ol0Co/VHO1VWJ41E+R10etNvaEqnULv45jVr2uyKVUDit4= Received: from AM4PR03MB1811.eurprd03.prod.outlook.com (10.167.88.147) by AM4PR03MB1810.eurprd03.prod.outlook.com (10.167.88.146) with Microsoft SMTP Server (TLS) id 15.1.517.8; Fri, 17 Jun 2016 17:04:41 +0000 Received: from AM4PR03MB1811.eurprd03.prod.outlook.com ([10.167.88.147]) by AM4PR03MB1811.eurprd03.prod.outlook.com ([10.167.88.147]) with mapi id 15.01.0517.014; Fri, 17 Jun 2016 17:04:41 +0000 From: "Paterson, Kenny" To: Ilari Liusvaara , Yoav Nir Thread-Topic: [TLS] Consensus call for keys used in handshake and data messages Thread-Index: AQHRyLpWJei848R7FkitH7EamdOzjw== Date: Fri, 17 Jun 2016 17:04:41 +0000 Message-ID: References: <95ACB42E-A0FF-4E46-87E9-212DAF033F42@gmail.com> <20160614190144.GA9787@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160614190144.GA9787@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [134.219.148.47] x-ms-office365-filtering-correlation-id: ebcb9345-368c-4aa0-1d32-08d396d1797c x-microsoft-exchange-diagnostics: 1; AM4PR03MB1810; 6:ENFlvLx3vi8hmGN8r61/ELDBR+NOeavSiROmZcxxuN7jCbybGQv96aB3oQoGvoVIn3bppkSt+ndBL200jmIQcohOzLZrQ15LUWcIjTOPMdRjvY9xGd9D4haaQ0hyrxRSvEUN/DW/eAEUkJu6BwXBr2LJdSLETS3rcMZxLvd0rz3PZtuhOX2h4F7tonhMMuU05cuUMUxZOGjqBGM96jYMwfM8mBpPiRhQGHe3yOWxbFShVBsNswiA8gbAxJy1E+l4t2+6XcQsK294aHEmAFFHSw0JbpHU7xq/3i/YMT9ij7s=; 5:YzgA/oBhyoZXNfj3LCAMQkoHneID1baj+3Vt2Bk+SA7T0yVo3TFLebwQOMcqLn6jGy2JmIpNa0QXsqp50S2EABYsLdbgkRmIOb9LsmlFsq5AKeT/S3qTpiTZoJYMSlEZDNaExafxAMU/36jSSczYJA==; 24:R21ckmRSb01JWwMPzA4N4byv7ycndglkvm9KRg75+Gd89xPrEux9b/MJ8ASQgtD1JYoy5ZeiF/hffRPAwzd0jXxnKUF1sTUty9hjmmlzpVk=; 7:qm+AxA0nDp7llyVW3Td+o8L81hckb52eaZDhBH3f1p3HZR3w4MtR2n/thnefFr/KYkPu1lqYUdqyQTeMNaSgFbXuDuuqwNX9/GEhmS2hp4MuxXczgMDJsLCpYE9cA6Al5hwDSxaU808ifwhr5esoePcN6ddBkBZULkL3u53AvQ/At6LMLvVLNDBKZa2rEJeOSZHGzi1JBnSicCn5DXxr0Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR03MB1810; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AM4PR03MB1810; BCL:0; PCL:0; RULEID:; SRVR:AM4PR03MB1810; x-forefront-prvs: 09760A0505 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(24454002)(199003)(76176999)(50986999)(15650500001)(105586002)(5001770100001)(54356999)(10400500002)(5002640100001)(19580395003)(122556002)(97736004)(4001350100001)(19580405001)(101416001)(8936002)(2906002)(4326007)(81166006)(81156014)(7846002)(8676002)(77096005)(106116001)(2950100001)(87936001)(15975445007)(74482002)(2900100001)(106356001)(3846002)(11100500001)(102836003)(6116002)(3280700002)(3660700001)(5004730100002)(86362001)(66066001)(36756003)(83506001)(68736007)(189998001)(92566002)(586003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR03MB1810; H:AM4PR03MB1811.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2016 17:04:41.8328 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1810 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 17 Jun 2016 17:08:08 -0000 SGkgSWxhcmksDQoNCk9uIDE0LzA2LzIwMTYgMjA6MDEsICJUTFMgb24gYmVoYWxmIG9mIElsYXJp IExpdXN2YWFyYSINCjx0bHMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaWxhcmlsaXVz dmFhcmFAd2VsaG8uY29tPiB3cm90ZToNCg0KPkkgdG9vIGhhdmVuJ3Qgc2VlbiBhbiBhcmd1bWVu dCAob3IgYW0gSSBhYmxlIHRvIGNvbnN0cnVjdCBvbmUNCj5teXNlbGYpIG9uIHdoeSB1c2luZyB0 aGUgc2FtZSBrZXkgY2F1c2VzIG1vcmUgaXNzdWVzIHRoYW4NCj4ibW9yZSBkaWZmaWN1bHQgZm9y IGNyeXB0b2dyYXBoZXJzIiAod2l0aG91dCBhc3N1bXB0aW9ucyBrbm93bg0KPnRvIGJlIGZhbHNl IG9yIGNhdXNlIHNldmVyZSBwcm9ibGVtcyBubyBtYXR0ZXIgd2hhdCkuDQo+DQo+DQo+U3VjaCBh cmd1bWVudHMgY291bGQgaW5jbHVkZSBlLmcuIGNyeXB0byBzY3JldyAobm8gcHJvb2Ygb2YNCj5l eHBsb2l0YWJpbGl0eSBuZWVkZWQpLCBpbXBsZW1lbnRhYmlsaXR5LCBuYXJyb3dpbmcgd29ya3Mt dnMtDQo+Y29ycmVjdCBnYXAsIGV0Yy4uLg0KPg0KPg0KPkFib3V0IGV2ZXJ5IG90aGVyIGlzc3Vl IEkgY291bGQgY29tZSB1cCB3aXRoLCBpdCBzZWVtcyB0byBiZSBqdXN0DQo+YXMgYmFkIHdpdGgg c2VwYXJhdGUga2V5cyBhbmQgcHVibGljIGNvbnRlbnQgdHlwZXMgKGV4Y2VwdCB0aG9zZQ0KPm9u ZXMgdGhhdCBhcmUganVzdCB3b3JzZSB3aXRoIHB1YmxpYyBjb250ZW50IHR5cGVzIG9mIGNvdXJz ZSkuDQo+DQoNClNpbmNlIG5vLW9uZSBlbHNlIHJlcGxpZWQ6IGl0J3MgYSBkZXRhaWxlZCB0ZWNo bmljYWwgaXNzdWUgYWJvdXQNCmNvbnN0cnVjdGluZyBwcm9vZnMgb2Ygc2VjdXJpdHkuIEF0IGEg dmVyeSBoaWdoIGxldmVsLCBhbmQgYXQgdGhlIHJpc2sgb2YNCm92ZXItc2ltcGxpZnlpbmcsIHRo ZSBtb3JlICJrZXkgc2VwYXJhdGlvbiIgeW91IGhhdmUsIHRoZSBlYXNpZXIgaXQgaXMgdG8NCmdl dCB0aGVtIHRvIGdvIHRocm91Z2guDQoNCk1heWJlIHNvbWVvbmUgZWxzZSB3aG8gaXMgbW9yZSBp bnRvIHRoZSBkZXRhaWxzIHRoYW4gbWUgY2FuIGNoaW1lIGluIHdpdGgNCnRoZSBuZXh0LWxldmVs IGV4cGxhbmF0aW9uLg0KDQpDaGVlcnMNCg0KS2VubnkgDQoNCj4NCj4NCj4tSWxhcmkNCj4NCj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPlRMUyBtYWls aW5nIGxpc3QNCj5UTFNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Rscw0KDQo= From nobody Fri Jun 17 10:23:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1AA12D8D8 for ; Fri, 17 Jun 2016 10:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaG_6TosjXj1 for ; Fri, 17 Jun 2016 10:23:32 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D997612D866 for ; Fri, 17 Jun 2016 10:23:31 -0700 (PDT) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (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 F412B2AA5E; Fri, 17 Jun 2016 19:23:29 +0200 (CEST) X-purgate-ID: 152705::1466184210-0000299C-C009CC09/0/0 X-purgate-size: 866 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 mail06.wdf.sap.corp (Postfix) with ESMTP id 9FA0B4EB156; Fri, 17 Jun 2016 19:23:28 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id A30D41A4EA; Fri, 17 Jun 2016 19:23:28 +0200 (CEST) In-Reply-To: <87mvmlw1qv.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor Date: Fri, 17 Jun 2016 19:23:28 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20160617172328.A30D41A4EA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 17:23:34 -0000 Daniel Kahn Gillmor wrote: > On Thu 2016-06-16 11:26:14 -0400, Hubert Kario wrote: >> wasn't that rejected because it breaks boxes that do passive monitoring >> of connections? (and so expect TLS packets on specific ports, killing >> connection if they don't look like TLS packets) > > We're talking about the possibility of changing the TLS record framing > anyway, which would kill the simplest of those boxes. One theory is if > you're going to make such a break, you might as well pull the band aid > off in one fell swoop. While I dislike monitoring boxes and hate intercepting proxies, changing of the TLS record framing (and hiding the ContentType) is going to break _the_endpoints_. If TLSv1.3 does that, its adoption curve will make IPv6 adoption appear fast by comparison. Please stop messing with the TLS record format. -Martin From nobody Fri Jun 17 13:19:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5944112DABA for ; Fri, 17 Jun 2016 13:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MIKwjEnigvD for ; Fri, 17 Jun 2016 13:19:05 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002: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 87A2612DAB5 for ; Fri, 17 Jun 2016 13:19:05 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id z186so81357596ywd.2 for ; Fri, 17 Jun 2016 13:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=xi5SE4X+5MEKzs26Ql7c2e6BqmYoTjO0Q6fvswW1Zmk=; b=ILztpwY2ggiYVRO6I0dGz83gobtKjh29Ka4Imbe+q8PqxmsJjXadPQLN4qeFqlLoPb +fhWvXb8jpCVaaYaHuxyirzyzormSoRwABKKrS7nSGGyEBII2D1XsS7/kpRJazAvYe5y TQsKEF7v9RPaZ6oxy7yCUZ+i7559HBmWHR99w0+RMrjjPEut/N96AACOEX+g0/bVkbMK QQCdscEgLSytMBJKNxI5Q381dae+pLvopx4YktvDCNM7lRxZqrmk1ME5huBhiIc4SbED zA8vroqfsp+uTbbPpMjBHRgIUHDPTcxX2+MoMtjfsdeyca2yo0ZwYJz2vzURrHTQNyeP G+dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=xi5SE4X+5MEKzs26Ql7c2e6BqmYoTjO0Q6fvswW1Zmk=; b=Sfv+KNBOJ9zrkBBwd//ee4VVuJONhRqYTXUd/ikx0Yy6kW4QMK1jp2iE7jizs5VZur 6FIN2/hYy3MFixBiIGjl2CHzN+68NwDuujZhhFGdozGbQ0Pp6V7bb3ATojwS42HUt6Zp HK1K5HcJcYQS65UCaTqq24rPnv/1O1lyEi+VfnTGZ0mq9KEpAtzMbu/Rp+LqHcR59Nxb 2BKMMwaRHRBOqkO5EKrPo0OPvRB9FpdslnNqR/jMQvgvFaLVfWTfbc9vIfjpEXfEgDnf p2zxzlYvJujcfNTSrj7dF9z957e2RhUP6JUyOyVKFRt8kw96SpbTzELOg0orKY/CSnrU Pk9Q== X-Gm-Message-State: ALyK8tJr82yaxnDn+3+pqKCkaxspHbBCCig5rIrqHzRLlDNfib4qnqznRRwHiN/6CiRyaZPaHqWs1WiHvOR6qQ== X-Received: by 10.129.117.132 with SMTP id q126mr2523023ywc.114.1466194744594; Fri, 17 Jun 2016 13:19:04 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.37.97.199 with HTTP; Fri, 17 Jun 2016 13:18:34 -0700 (PDT) In-Reply-To: References: From: Hugo Krawczyk Date: Fri, 17 Jun 2016 16:18:34 -0400 X-Google-Sender-Auth: yDy8HMQbOieFvSsC73238UN3TUs Message-ID: To: Joseph Salowey Content-Type: multipart/alternative; boundary=001a1147f6c6ec563a05357f10f5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 17 Jun 2016 20:19:08 -0000 --001a1147f6c6ec563a05357f10f5 Content-Type: text/plain; charset=UTF-8 I am abstaining on the choice of alternative 1 and 2 since I do not understand enough the engineering considerations and ramifications of the different choices. Also, I have not put any thought into the privacy issues related to hiding content type and I certainly did not do any formal analysis of these aspects. I do want to say that from a cryptographic design and analysis point of view, key separation is of great importance. It allows to have more modular analysis and design, and prove composability properties of protocols and applications. I believe it has significant practical advantages particularly with respect to "maintaining" a protocol, namely, making sure that changes and extensions to a protocol are secure and do not jeopardize its security. The more modular the design the easier it is to reason about changes and additions to the protocol (and for a protocol like TLS, future changes and adaptations to different settings are unavoidable). As for the specific cryptographic considerations in TLS 1.3, I would have "fought" greatly to preserve key separation at the level of the basic handshake protocol (three first flights). It guarantees that the application key is *fresh* at its first use for protecting application data. Freshness means that the key can serve any purpose for which a shared random secret key can be used. (In contrast, a non-fresh key, e.g. one used during the handshake itself, can only be used with applications that are aware of how exactly the key was used in the handshake.) Since my understanding is that the current base-handshake specification does preserve the freshness of the application key, I am happy with that design. The issue of using the application key to protect post-handshake messages is more involved. First, post-handshake client authentication authenticates ("a posteriori") the application key but only after this key has already been used. In this sense this mechanism cannot possibly achieve key freshness for the application key. The best one can hope for is that this post-authentication authenticates the key without jeopardizing its use in the particular application it is intended for, namely, protecting TLS record layer data. Luckily, this can be proved. So now the question is whether using the application key to encrypt the very messages that provide post-handshake authentication (e.g., client's signature) may lower the security of this key. The answer is that it does not. That is, the security of the key for protecting record layer data is not jeopardized by using it to encrypt post-handshake messages. I feel moderately confident about the above paragraph as I have been working on the analysis of client authentication, including (encrypted) post-handshake authentication. On the other hand, I have not studied the effects of encrypting other post-handshake messages such as New Ticket or re-keying messages so I don't have an "educated conclusion" here. I do expect that there are analytical advantages for not using the application key for encrypting these messages but I cannot say for sure. In all, it is good and prudent practice (not just theory) to enforce key separation wherever possible, and I would be happier if there was no instance where the application key is applied to non-application data. But I also know that one has to weigh other engineering considerations and in this case the trade-off does not seem obvious to me. Hence, as said, I abstain. Hugo On Mon, Jun 13, 2016 at 3:00 PM, Joseph Salowey wrote: > For background please see [1]. > > Please respond to this message indicating which of the following options > you prefer by Monday June, 20, 2016 > > 1. Use the same key for handshake and application traffic (as in the > current draft-13) > > or > > 2. Restore a public content type and different keys > > Thanks, > > J&S > > > [1] https://www.ietf.org/mail-archive/web/tls/current/msg20241.html > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a1147f6c6ec563a05357f10f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am abstaining on the choice of alternative 1 and 2 since I do n= ot understand
enough the engineering considerations and ramifications of t= he different
choices. Also, I have not put any thought into the privacy is= sues related to
hiding content type and I certainly did not do any formal = analysis of these
aspects.=C2=A0
=
I do want to say that from a crypt= ographic design and analysis point of view,
key separation is of great imp= ortance. It allows to have more modular analysis
and design, and prove com= posability properties of protocols and applications.
I believe it has sign= ificant practical advantages particularly with respect to
"maintainin= g" a protocol, namely, making sure that changes and extensions to a
p= rotocol are secure and do not jeopardize its security. The more modular the=
(and for a protocol like TLS, future changes and adaptations to diffe= rent
settings are unavoidable).
<= font face=3D"verdana, sans-serif">
As for the specific cryptographic c= onsiderations in TLS 1.3, I would have
"fought" greatly to prese= rve key separation at the level of the basic handshake
protocol (three fir= st flights). It guarantees that the application key is=C2=A0
*fresh* at it= s first use for protecting application data. Freshness means that
the key = can serve any purpose for which a shared random secret key can be used.
(I= n contrast, a non-fresh key, e.g. one used during the handshake itself, can=
in the handshake.) Since my understanding is that the current b= ase-handshake
specification does preserve the freshness of the application= key, I am happy
with that design.

The issue of using the applicati= on key to protect post-handshake messages is
more involved. First, post-ha= ndshake client authentication authenticates ("a
posteriori") the= application key but only after this key has already been used.
In this se= nse this mechanism cannot possibly achieve key freshness for the
applicati= on key. The best one can hope for is that this post-authentication
authent= icates the key without jeopardizing its use in the particular application
= it is intended for, namely, protecting TLS record layer data. Luckily, this= can
be proved. So now the question is whether using the application key t= o encrypt
the very messages that provide post-handshake authentication (e.= g., client's
signature) may lower the security of this key. The answer= is that it does not.
That is, the security of the key for protecting re= cord layer data is not
jeopardized by using it to encrypt post-handshake = messages.

I feel moderately confident about the above paragraph as I= have been working on
the analysis of client authentication, including (= encrypted) post-handshake
authentication. On the other hand, I have not st= udied the effects of encrypting
other post-handshake messages such as New = Ticket or re-keying messages so I
= don't have an "educated conclus= ion" here. I do expect that there are analytical
advantages for not u= sing the application key for encrypting these messages but I
cannot say fo= r sure.

In all, it is good and prudent practice (not just theory) to= enforce key
separation wherever possible, and I would be happier if there= was no instance
where the application key is applied to non-application d= ata. But I also know
that one has to weigh other engineering consideration= s and in this case the
trade-off does not seem obvious to me. Hence, as s= aid, I abstain.

Hugo


On Mon, Jun 13, 2016 at 3:00 PM, Joseph Salowey <joe@salo= wey.net> wrote:
For background please see [1].

Please respond to= this message indicating which of the following options you prefer by Monda= y June, 20, 2016=C2=A0

1. Use the same key fo= r handshake and application traffic (as in the current draft-13)
=

or

2. Restore a public content type and different keys

Thanks,

J&S=



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


--001a1147f6c6ec563a05357f10f5-- From nobody Sun Jun 19 03:51:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBA712D0AB for ; Sun, 19 Jun 2016 03:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0-qu-qxU8kB for ; Sun, 19 Jun 2016 03:51:14 -0700 (PDT) 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 DD77612B078 for ; Sun, 19 Jun 2016 03:51:13 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id t190so44685279pfb.3 for ; Sun, 19 Jun 2016 03:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=rwT5g+XYL4koY8nYi75+5J4rn7en+2n/X2Iq3zyT0A8=; b=A5FxPHjoU1ONyCM7MtwgdPf79LkDpg+B0eHSyOFOlvVwAGjiiXv+SfoBE7w3WAxrCU hVoiP4tXd2OJdZ7c/Lt4k3fzjnsDcHzMrT0gP0K81AMlXeK8MMiqdWNnUPh64PWxFdH7 UJ+TvxpXy3nQSUGE3pzANoFar/iUe8ObWViVI= 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:from:in-reply-to:date:cc :message-id:references:to; bh=rwT5g+XYL4koY8nYi75+5J4rn7en+2n/X2Iq3zyT0A8=; b=Hlo2DMGudMHv8FeRqMNHbsM8Z7ooUa+3sj5SCsAmu3SUooQPZ/9xHPTh93a1dWSgZS 7ZYP/Dd9YlvMZY1m4JJHgAJckaQqX0oSWIxkWfBlaFwH2gGdvZte0jaGsBjFaREOyBX5 NZ1xy2ZH0KdrAAmG6mwOPya5+EDkbs3l+cQoqOw+6AoKmNx6N3/tabO/lrTToZyzobGp oetI9vuN6z1ofm+dceB44/m+w9s1gBVqRCOpWUkZtF2o6UBEwJVHKlBGE36Ic/tn5V0Y LO7H5BwiTteu17mnt5bpxFo5INYRGj5RxPVcuZTCIs03513y4ySYBaSlFygDax+ni+Kl zWtA== X-Gm-Message-State: ALyK8tJDEgMFIZzqaeIdd5C5s497KhoyLHhAKvbE4uL/ZZPxvGngB+qwKWBAKEawIxxrbQ== X-Received: by 10.98.12.22 with SMTP id u22mr14626862pfi.80.1466333469588; Sun, 19 Jun 2016 03:51:09 -0700 (PDT) Received: from [192.168.1.234] ([114.124.2.4]) by smtp.gmail.com with ESMTPSA id 189sm80549735pfd.18.2016.06.19.03.51.07 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Jun 2016 03:51:08 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_07084C21-CC72-4F4D-B632-1D88F5A6FFA8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Aaron Zauner In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C9CA49@uxcn10-5.UoA.auckland.ac.nz> Date: Sun, 19 Jun 2016 18:51:03 +0800 Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C73F4C9CA49@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [TLS] Adoption of TLS-LTS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 19 Jun 2016 10:51:15 -0000 --Apple-Mail=_07084C21-CC72-4F4D-B632-1D88F5A6FFA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > On 06 Jun 2016, at 21:05, Peter Gutmann = wrote: >=20 > TLS-LTS, https://tools.ietf.org/html/draft-gutmann-tls-lts-03, has = more or > less stabilised, incorporating all the feedback I've had for it = (there's only > one open question still remaining), so I'd like to request that it now = be > adopted as a WG item. >=20 > I'd also like to request an early/temporary assignment for an = extension ID, to > provide something a bit more usable than the much-overloaded 0x42 = that's > currently being used. Although I appreciate the effort, I have to agree with previous = comments: we're working on TLS 1.3 -- I do not support the adoption of = this draft. Aaron --Apple-Mail=_07084C21-CC72-4F4D-B632-1D88F5A6FFA8 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----- iQIcBAEBCgAGBQJXZnkYAAoJEOTbZJL9ubXVBIoP/2Y9sKuXcGwGHpxPDVolkITM E8EE6AEzyj4rB+xA+DmpFbqWDrrGtxypbUwdIqGq/L0M7THKrCf4m89STENWJfuY RZ0IhfMMrlbd7bXdQW/rOnaOqcee+NEUgh/IN8MpqU5zDe7HIWt26CbMnIOIWwC+ WGEtimzsWlaio6p+MU1bi60+yKbcclv94UfdhJcfrWP0XZoFfySG8zBBMiBBKM2J R6x6nrmcOTjBY+IdYgUS+hmmbYLIQo8p7iGUrbDCKMDxt+VZfeduh2WzWi4UqEav UmlvEktp8FZXpGcPxxgZoJKdLk/SQDLSQug8nu1JNx/iCArR7JZO3p0vuBNvYTeb jm74zGpjl2WTGd9AxA2VXUwthlxZBACgMuwnQ3mCDjcrOAxbOrwM3p9ObOpB82LE Iz7jELyid1Kp9fEhsXzouIG+Odsw58RTBmMhIZScU/SGKdPYlKMao7u9bMlOlmDm ZzmqrubUEeP2nqBJIXju/ihWfg9TJFvDSIBF2os3wMO2y8D6XSM1PkEHcgYWMbUK oxzc8WY1jsS+4NOr/80GiGZ8cpvidq4M4+Iy3izQ72hhas63ymhFwZxojPUQTbia VpjwfDGmTDFsuwjCAnH5rrXwhL6v3cWpaLtThJd95lGeSLafXZqqMSF4tkNfGUGe HA2CdBsnwqpXAr9Dknjo =e7iY -----END PGP SIGNATURE----- --Apple-Mail=_07084C21-CC72-4F4D-B632-1D88F5A6FFA8-- From nobody Mon Jun 20 06:33:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC04B12B069 for ; Mon, 20 Jun 2016 06:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l90_LSw2OTBl for ; Mon, 20 Jun 2016 06:33:55 -0700 (PDT) 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 5FEBF12B060 for ; Mon, 20 Jun 2016 06:33:55 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id f126so69707346wma.1 for ; Mon, 20 Jun 2016 06:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=R4tpwctaSpOADns+NgQdi4g1HKYGfc/Tdz9wiegKL8E=; b=IGRUbWg/5U4bGLjUvagj94oBMRlEe396CxKvUwXDUom105DUhYtqh0pdxv/azuQcoO XES1/Bv8PsLcSJpEfWaF4Q1fnRzo92bOsEI3qjKe4QhCshVeGA5cxWFyP+3k9HuWDb3X P2M9aD8qkm4oHFRcJ4Hztsl33WLgVdBYN0UPfmUCTNCSRYWMbjm6giXIccBjl+f9pvha fbq6KuEI+moykvLnA+5LU1yBF6H5a28dgRuQNO+h9QSRmgsrAgVXVcfGTZNijgDjP0aq 6Q/6ZASHiclqrMA8iRE4VMof3Bo2qRfWIWgxROS1lsbVOtog3Dpqd9bCdlFMjFu7JWSL 3Tfw== 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; bh=R4tpwctaSpOADns+NgQdi4g1HKYGfc/Tdz9wiegKL8E=; b=S8lKcB9+RD65vkct/tEIn0CiRpl1uqyBZAslFwso5MEfau3ofnDmfpGxJpLo0gtUpJ lLofq7AIl+vKUZ5zdpe1tdX1tSn0GeDwgDb2LxVpCFXgBGngyBLtWVCbnKFJYgsc0TyN C9WNwgf3L+Ale6WISi1XnPJOFe3lvZwKPpRDRPSENvnvUVzrbYfIz2xcJZbQ5StHhEp2 cwfiUVMaO0GighRuVtKcq2ELNdy/KGRSFp8pLm87oPozGodcSueeCKWZleeGSnDz7Cvy o0i+Lq/NdADWnP+JRCneV97uJcyaq7SreC0Y4j6KbJXfOIHjB/CxxB00N3OCrdFqJPo9 UWHQ== X-Gm-Message-State: ALyK8tJuIirQrWESDgx84goixQFX6gPjGzLEBFKhwydiZlzkaRjEEnzZN1K2FgVm9nYEMOeQnjYaLXFayoHWzA== MIME-Version: 1.0 X-Received: by 10.194.201.70 with SMTP id jy6mr16436176wjc.150.1466429633871; Mon, 20 Jun 2016 06:33:53 -0700 (PDT) Received: by 10.28.29.14 with HTTP; Mon, 20 Jun 2016 06:33:53 -0700 (PDT) Received: by 10.28.29.14 with HTTP; Mon, 20 Jun 2016 06:33:53 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Jun 2016 15:33:53 +0200 Message-ID: From: Maarten Bodewes To: David Benjamin Content-Type: multipart/alternative; boundary=047d7b874aba6a463f0535b5c1b1 Archived-At: Cc: IETF TLS Subject: Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 20 Jun 2016 13:33:58 -0000 --047d7b874aba6a463f0535b5c1b1 Content-Type: text/plain; charset=UTF-8 Hi David, Great. Thanks for following up on this! I think I now understand why the implementation of DH seemed buggy in one of the crypto libraries that I was reviewing. Regards, Maarten Op 19 mei 2016 21:22 schreef "David Benjamin" : > If the WG agrees with this change, I've put together a PR here: > https://github.com/tlswg/tls13-spec/pull/462 > > On Tue, May 17, 2016 at 4:14 PM David Benjamin > wrote: > >> Reviving this thread, I also think it would also be a good idea if 1.3 >> did not stripping zeros from Z. Having this logic is rather dubious w.r.t. >> treating secret data in constant-time. And as Bill Cox mentioned >> elsewhere in this thread, this odd behavior has caused interoperability >> issues in the past. >> >> I don't think we have to be worried about inconsistency with 1.2 as, by >> the time this happens, we will already know we're speaking 1.3. TLS 1.3 DHE >> is already a very different beast from TLS 1.2 DHE. At this point, the only >> thing they meaningfully share is they happen to use the same code points. >> >> David >> >> On Thu, Apr 7, 2016 at 10:37 AM Russ Housley >> wrote: >> >>> I would prefer to always use the full, known-length byte string for Z. >>> In my experience, it is better to know the lengths of byte strings instead >>> of stripping leading zeroes. The difference in the speed of the HKDF >>> computation by omitting the leading zeros is not significant. Alignment >>> with NIST SP 800-56A is nice, but it is not the reason for my preference. >>> >>> Russ >>> >>> >>> On Mar 28, 2016, at 11:56 AM, Maarten Bodewes >>> wrote: >>> >>> > Hi all, >>> > >>> > I see that the leading zero is stripped off of the value of Z (the >>> shared secret) before it is used as input to HKDF. This seems to be >>> compatible with TLS 1.2. Then again, it is not compatible with e.g. >>> NISP800-56A which uses the value of Z with the same size of the prime in >>> octets. Furthermore, it is also different with regards to handling the >>> coordinate X as used in ECDH. >>> > >>> > Was this a conscious decision to keep compatibility with TLS? Has the >>> use of the value of Z including zero octets been considered? >>> > >>> > Regards, >>> > Maarten >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> --047d7b874aba6a463f0535b5c1b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi David,

Great. Thanks for following up on this!

I think I now understand why the implementation of DH seemed= buggy in one of the crypto libraries that I was reviewing.

Regards,
Maarten

Op 19 mei 2016 21:22 schreef "David Benjami= n" <davidben@chromium.org<= /a>>:
If the WG agrees with this change, I've put together a PR here:https://github.com/tlswg/tls13-spec/pull/462

On Tue, May 17, 2016 at 4:14 PM David Benjamin &= lt;davidben@chro= mium.org> wrote:
Reviving this thread, I also think it would also be a good idea if 1.= 3 did not stripping zeros from Z. Having this logic is rather dubious w.r.t= . treating secret data in constant-time.=C2=A0And as Bill Cox mentioned elsewhere in this thread, this odd behavior ha= s caused interoperability issues in the past.

I d= on't think we have to be worried about inconsistency with 1.2 as, by th= e time this happens, we will already know we're speaking 1.3. TLS 1.3 D= HE is already a very different beast from TLS 1.2 DHE. At this point, the o= nly thing they meaningfully share is they happen to use the same code point= s.

<= div dir=3D"ltr">
David

On Thu, Apr 7, 2016 at 10:37 AM Russ Housley <housley@vigilsec.com> wrote:
=
I would prefer to always use the full,= known-length byte string for Z.=C2=A0 In my experience, it is better to kn= ow the lengths of byte strings instead of stripping leading zeroes.=C2=A0 T= he difference in the speed of the HKDF computation by omitting the leading = zeros is not significant.=C2=A0 Alignment with NIST SP 800-56A is nice, but= it is not the reason for my preference.

Russ


On Mar 28, 2016, at 11:56 AM, Maarten Bodewes <maarten.bodewes@gmail.com> wro= te:

> Hi all,
>
> I see that the leading zero is stripped off of the value of Z (the sha= red secret) before it is used as input to HKDF. This seems to be compatible= with TLS 1.2. Then again, it is not compatible with e.g. NISP800-56A which= uses the value of Z with the same size of the prime in octets. Furthermore= , it is also different with regards to handling the coordinate X as used in= ECDH.
>
> Was this a conscious decision to keep compatibility with TLS? Has the = use of the value of Z including zero octets been considered?
>
> Regards,
> Maarten

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--047d7b874aba6a463f0535b5c1b1-- From nobody Mon Jun 20 17:39:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434D512D86D for ; Mon, 20 Jun 2016 17:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94Q9soaRnJVp for ; Mon, 20 Jun 2016 17:39:52 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 3EAA412D84F for ; Mon, 20 Jun 2016 17:39:52 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id i12so767587ywa.1 for ; Mon, 20 Jun 2016 17:39:52 -0700 (PDT) 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; bh=X2anUbegAQSgS45zi0FDcAX/CRvKnQsqEr21vyogVsY=; b=uB78sErWwRzfsI7FZ+MkqrI31NLWSjTqjmXa3A6VsWvanJORDaYhih9vTQi/fCQtzk ZkICviCZJcH4769s9m/WsR1c9pwjgCxReBR8buSPLSqeFkFk+80xQjwXUOuSETy2N4SY +VOolE3NT2SOYFOgBVay7mDgxVouUsOdFcC/jDeiEOkqqp7KxWTDuKZ8mTPk0xPGq2v0 1EkgViytVj1yf2AhaotkizTyu+s40pRhm06FO/sUknW12VjZ4seC3mtvv+Rx94OgBIZz pwvnBTVL4Jo1dQ5nn34MlDXU70hKPq4z6Kzq6JbE3KnhzU0KDX8baBJayhYI0513IrC+ a9Yg== 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; bh=X2anUbegAQSgS45zi0FDcAX/CRvKnQsqEr21vyogVsY=; b=MljntovsmqY62mL0MtL/Q4IBxL74F/2DnX6NmNjWWvs8pZFZ7G04f7vuUWFP+2oC7u fSNl7Nz8Lv+p9EqMdxc7FP/15huX6xk0In6NiBKMtZCb50bGix4v8FcQgHxKk5n+bLHJ uPVHill61yOid/6Ra+3OATCX67RZFNNGBAWkcN7SuSn8m1IMpX5c0WuhNP72E/PRliLf qJ12co8/sdCf6sNUn7kKyyq0NxijXMfxndnGshjmoPO40PN81JNOcejf8qsvshMjJAOz mx9Lo8ogCqy75l1OjyaE3HklnQZ5+wAeq4Aupdlg0vEER3RsxoP9LbsTgitZBQ7Rfjyb 9HpQ== X-Gm-Message-State: ALyK8tLqC5Phg1bBwjQ2XdNf24GbmZG4r7NfT2PYmoZB5DVXxNM9y2ocuqlUWJyccqD3ZMLbotehCoENNiItTw== X-Received: by 10.129.83.213 with SMTP id h204mr11613285ywb.276.1466469591391; Mon, 20 Jun 2016 17:39:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.136 with HTTP; Mon, 20 Jun 2016 17:39:11 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 20 Jun 2016 17:39:11 -0700 Message-ID: To: Hugo Krawczyk Content-Type: multipart/alternative; boundary=001a114d8e1611a4a80535bf0fbc Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Jun 2016 00:39:55 -0000 --001a114d8e1611a4a80535bf0fbc Content-Type: text/plain; charset=UTF-8 Nobody seems super-excited about either Option 1 or Option 2, so it's at least worth noting that there's one of the options I claimed was rejected earlier, namely separately encrypting the content type in roughly the manner suggested by DKG, Ilari, and Kenny. Thanks for Doug/Felix for prompting me on this. NOTE: I don't promise any of the below is secure, though it probably can be made so with enough work. Actually doing so is an exercise for the reader. The basic idea is as follows: 1. In each direction generate a separate "content_type_key" 2. Separately encrypt the content type from the rest of the record using the content_type_key. 3. On the receiving side, first decrypt the content type and then use that to determine what key to decrypt the record. The trivial version of this is just to AEAD encrypt the content type separately, but this has unacceptable bandwidth and CPU properties, so is probably not viable. However, there are more efficient designs, which can get the overhead down to modest levels (<= 1 byte of expansion and <=1/16 of a block computation/record). The obvious construction is to use the content_type_key to compute a per-record masking value (effectively an ad hoc stream cipher) and then use that to encrypt the content type (or potentially just a key type bit) without integrity (though you might later protect it in the additional data block under the main key). This gives you an encryption function without expansion. If you have a mask function which outputs one block at a time, you can use pieces of the block for each record (e.g., for record N you use byte N/16) [1] Obvious objections to this: 1. This isn't integrity protected. This is probably the most serious complaint and has the potential to actually leak information about the content type unless you're careful [2], even if you eventually integrity protect this information. 2. It's odd to just use a piece of the AEAD cipher (the encryption function), especially if we ever had a really non-composite cipher. This can be alleviated by using HKDF-Expand to produce the stream of bits. 3. Maybe it doesn't get the whole job done, especially wrt the fact that we're not rekeying the app data after client auth. 4. It's gross. Yes, yes it is. I'm not really in love with this idea, but I did want people to know that maybe we don't *have* to choose between option 1 and option 2 in case that changes people's opinions. -Ekr [0] Note, I'm specifically not trying to protect length here. That might be attractive, but my sense is that for the reasons Kenny indicates it's harder to get right and I'm generally pretty skeptical of length hiding in TLS given that we already have added padding. [1] There are some subtleties about not breaking the record format. If we don't care, then we can strip the first three bytes and then steal a bit from the length to use for "key type" (the length will never hage the high bit set). If we do care, then we could use the key bit to toggle between "app data" and "handshake" in the dummy record type byte. [2] Naively, if you try encrypting the whole content type, some transformations on the encrypted value will produce invalid types, which leaks information if the receiver sends an alert. On Fri, Jun 17, 2016 at 1:18 PM, Hugo Krawczyk wrote: > I am abstaining on the choice of alternative 1 and 2 since I do not > understand > enough the engineering considerations and ramifications of the different > choices. Also, I have not put any thought into the privacy issues related > to > hiding content type and I certainly did not do any formal analysis of these > aspects. > > I do want to say that from a cryptographic design and analysis point of > view, > key separation is of great importance. It allows to have more modular > analysis > and design, and prove composability properties of protocols and > applications. > I believe it has significant practical advantages particularly with > respect to > "maintaining" a protocol, namely, making sure that changes and extensions > to a > protocol are secure and do not jeopardize its security. The more modular > the > design the easier it is to reason about changes and additions to the > protocol > (and for a protocol like TLS, future changes and adaptations to different > settings are unavoidable). > > As for the specific cryptographic considerations in TLS 1.3, I would have > "fought" greatly to preserve key separation at the level of the basic > handshake > protocol (three first flights). It guarantees that the application key is > *fresh* at its first use for protecting application data. Freshness means > that > the key can serve any purpose for which a shared random secret key can be > used. > (In contrast, a non-fresh key, e.g. one used during the handshake itself, > can > only be used with applications that are aware of how exactly the key was > used > in the handshake.) Since my understanding is that the current > base-handshake > specification does preserve the freshness of the application key, I am > happy > with that design. > > The issue of using the application key to protect post-handshake messages > is > more involved. First, post-handshake client authentication authenticates > ("a > posteriori") the application key but only after this key has already been > used. > In this sense this mechanism cannot possibly achieve key freshness for the > application key. The best one can hope for is that this post-authentication > authenticates the key without jeopardizing its use in the particular > application > it is intended for, namely, protecting TLS record layer data. Luckily, > this can > be proved. So now the question is whether using the application key to > encrypt > the very messages that provide post-handshake authentication (e.g., > client's > signature) may lower the security of this key. The answer is that it does > not. > That is, the security of the key for protecting record layer data is not > jeopardized by using it to encrypt post-handshake messages. > > I feel moderately confident about the above paragraph as I have been > working on > the analysis of client authentication, including (encrypted) post-handshake > authentication. On the other hand, I have not studied the effects of > encrypting > other post-handshake messages such as New Ticket or re-keying messages so I > don't have an "educated conclusion" here. I do expect that there are > analytical > advantages for not using the application key for encrypting these messages > but I > cannot say for sure. > > In all, it is good and prudent practice (not just theory) to enforce key > separation wherever possible, and I would be happier if there was no > instance > where the application key is applied to non-application data. But I also > know > that one has to weigh other engineering considerations and in this case the > trade-off does not seem obvious to me. Hence, as said, I abstain. > > Hugo > > > On Mon, Jun 13, 2016 at 3:00 PM, Joseph Salowey wrote: > >> For background please see [1]. >> >> Please respond to this message indicating which of the following options >> you prefer by Monday June, 20, 2016 >> >> 1. Use the same key for handshake and application traffic (as in the >> current draft-13) >> >> or >> >> 2. Restore a public content type and different keys >> >> Thanks, >> >> J&S >> >> >> [1] https://www.ietf.org/mail-archive/web/tls/current/msg20241.html >> >> _______________________________________________ >> 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 > > --001a114d8e1611a4a80535bf0fbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nobody seems super-excited about either Option 1 or O= ption 2, so it's
at least worth noting that there's one o= f the options I claimed was
rejected earlier, namely separately e= ncrypting the content type in
roughly the manner suggested by DKG= , Ilari, and Kenny. Thanks for
Doug/Felix for prompting me on thi= s.


NOTE: I don't promise any of= the below is secure, though it probably
can be made so with enou= gh work. Actually doing so is an exercise
for the reader.


The basic idea is as follows:
1. In each direction generate a separate "content_type_ke= y"
2. Separately encrypt the content type from the rest of t= he record
=C2=A0 =C2=A0using the content_type_key.
3. O= n the receiving side, first decrypt the content type and then use
=C2=A0 =C2=A0that to determine what key to decrypt the record.
<= br>
The trivial version of this is just to AEAD encrypt the conte= nt type
separately, but this has unacceptable bandwidth and CPU p= roperties, so
is probably not viable. However, there are more eff= icient designs,
which can get the overhead down to modest levels = (<=3D 1 byte of
expansion and <=3D1/16 of a block computati= on/record).

The obvious construction is to use the= content_type_key to compute a
per-record masking value (effectiv= ely an ad hoc stream cipher) and
then use that to encrypt the con= tent type (or potentially just a key
type bit) without integrity = (though you might later protect it in the
additional data block u= nder the main key). This gives you an
encryption function without= expansion. If you have a mask function
which outputs one block a= t a time, you can use pieces of the block for
each record (e.g., = for record N you use byte N/16) [1]


Obvious objections to this:
1. This isn't integrity protecte= d. This is probably the most serious
complaint and has the potent= ial to actually leak information about
the content type unless yo= u're careful [2], even if you eventually
integrity protect th= is information.

2. It's odd to just use a piec= e of the AEAD cipher (the encryption
function), especially if we = ever had a really non-composite cipher.
This can be alleviated by= using HKDF-Expand to produce the stream
of bits.

<= /div>
3. Maybe it doesn't get the whole job done, especially wrt th= e fact
that we're not rekeying the app data after client auth= .

4. It's gross. Yes, yes it is.

I'm not really in love with this idea, but I= did want people to know
that maybe we don't *have* to choose= between option 1 and option 2
in case that changes people's = opinions.

-Ekr


=
[0] Note, I'm specifically not trying to protect length here. That=
might be attractive, but my sense is that for the reasons Kenny<= /div>
indicates it's harder to get right and I'm generally pret= ty skeptical
of length hiding in TLS given that we already have a= dded padding.

[1] There are some subtleties about = not breaking the record format.
If we don't care, then we can= strip the first three bytes and then
steal a bit from the length= to use for "key type" (the length will
never hage the = high bit set). If we do care, then we could use the
key bit to to= ggle between "app data" and "handshake" in the dummy
record type byte.

[2] Naively, if you try = encrypting the whole content type, some
transformations on the en= crypted value will produce invalid types,
which leaks information= if the receiver sends an alert.


On Fri, Jun 17, 2016 at 1:18 PM, = Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
= I am abstaining on the choice of alterna= tive 1 and 2 since I do not understand
enough the engineering consideratio= ns and ramifications of the different
choices. Also, I have not put any th= ought into the privacy issues related to
hiding content type and I certain= ly did not do any formal analysis of these
aspects.=C2=A0

I do want= to say that from a cryptographic design and analysis point of view,=
key s= eparation is of great importance. It allows to have more modular analysis
= and design, and prove composability properties of protocols and application= s.
I believe it has significant practical advantages particularly with res= pect to
"maintaining" a protocol, namely, making sure that chang= es and extensions to a
protocol are secure and do not jeopardize its secu= rity. The more modular the
design the easier it is to reason about changes= and additions to the protocol
(and for a protocol like TLS, future change= s and adaptations to different
settings are unavoidable).

As for th= e specific cryptographic considerations in TLS 1.3, I would have
"fou= ght" greatly to preserve key separation at the level of the basic hand= shake
protocol (three first flights). It guarantees that the application k= ey is=C2=A0
*fresh* at its first use for protecting application data. Fres= hness means that
the key can serve any purpose for which a shared random s= ecret key can be used.
(In contrast, a non-fresh key, e.g. one used durin= g the handshake itself, can
only be used with applications that are aware = of how exactly the key was used=C2=A0
in the handshake.) Since my understa= nding is that the current base-handshake
specification does preserve the f= reshness of the application key, I am happy
with that design.
=

=
The i= ssue of using the application key to protect post-handshake messages is
mo= re involved. First, post-handshake client authentication authenticates (&qu= ot;a
posteriori") the application key but only after this key has alr= eady been used.
In this sense this mechanism cannot possibly achieve key f= reshness for the
application key. The best one can hope for is that this p= ost-authentication
authenticates the key without jeopardizing its use in t= he particular application
it is intended for, namely, protecting TLS recor= d layer data. Luckily, this can
be proved. So now the question is whether = using the application key to encrypt
the very messages that provide post-h= andshake authentication (e.g., client's
signature) may lower the secur= ity of this key. The answer is that it does not.
That is, the security of = the key for protecting record layer data is not
jeopardized by using it to= encrypt post-handshake messages.
=
I feel moderately confident about = the above paragraph as I have been working on
the analysis of client authe= ntication, including (encrypted) post-handshake
authentication. On the oth= er hand, I have not studied the effects of encrypting
other post-handshake= messages such as New Ticket or re-keying messages so I
don't have an = "educated conclusion" here. I do expect that there are analytical=
cannot say for sure.

In all, it is good and prudent practic= e (not just theory) to enforce key
separation wherever possible, and I wou= ld be happier if there was no instance
where the application key is applie= d to non-application data. But I also know
that one has to weigh other eng= ineering considerations and in this case the
trade-off does not seem obvio= us to me. Hence, as said, I abstain.

Hugo

On Mon, Jun 13, 2016 at 3:00= PM, Joseph Salowey <joe@salowey.net> wrote:
For backgr= ound please see [1].

Please respond to this messag= e indicating which of the following options you prefer by Monday June, 20, = 2016=C2=A0

1. Use the same key for handshake = and application traffic (as in the current draft-13)

or

2. <= /span>Restore a public content type and different keys
<= br>
Thanks,

__________________________________________= _____
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


--001a114d8e1611a4a80535bf0fbc-- From nobody Mon Jun 20 18:15:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E812E12DAEB for ; Mon, 20 Jun 2016 18:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTRPMlp3s7OG for ; Mon, 20 Jun 2016 18:15:42 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010: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 3B42712DAE9 for ; Mon, 20 Jun 2016 18:15:42 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id q132so1540889lfe.3 for ; Mon, 20 Jun 2016 18:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=6aZ+rfnI8WkcBUGjhi2pPHRvdAixhDhvDFRWux12IMs=; b=ImFCZjiLT6E/Mj7hQcZE1JcJhYstABq+Vjzhwtk4AJmdW5uOwQJDQXobxu/77wKykw adY/XpH2jN5Bs7OIJFiJCxJZHhMzYk8B250F0cb1dp50DXDER9d16KkYavV1yYEGp9rR GN4lep8P04Sy+r88wunHdIHsTRF5ZyqQxlrK2qFK/hmn3NSZtzI2lFl29e7s3c6p/S4w NrK7tEzU3XMVWE2iJCal4+2HNiSTwhxu3ffStL5/OXeLzLWY+Ba4VrQEpYFe9pL4DdiM cvg7k9JKuGltCawTlaBnLC4dCBDA0jeHXHvV6FBGMMJ8hZfnudM0lSslf98YXXfGX64U BKJg== 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; bh=6aZ+rfnI8WkcBUGjhi2pPHRvdAixhDhvDFRWux12IMs=; b=dxZAwePIoDq0H7QjMZAjEcph8zEV3lICuFVbyx/Am0i8TbRpbBQnzQ2aCp3Hzpl2p9 b0nekSfFM12O6ax5ErE1XwJMmuWbfGp30jEJC3EJiuswr6Y4ZhNMlQ096MXjx4UX7/9Y tPOC/d4Z+le8tk2s32QWT3YMViuB2DRAK7gyLt+Y8iJ+71PoD9S3FWIYiAG1Rw5PptSv 7B8EcNpjygHFgBejz2OwBmER8Arv2/qqz14UC/nrC9C0LPsrew6E7AOerRkopfdHonmD xUyJtEfZVmWuTAXSfIlUH02HLF5zFsB8X7eVNojm0EKcjorP1w1PicXboSLVokVa4i+9 r73w== X-Gm-Message-State: ALyK8tKKiVocj+A9/qk8sWe1O/nmt5+lsP9M6yRUa+pbeauatohavlyDuKr6QZ2HRb8Qlz4gtW8ruAai+RQqTw== X-Received: by 10.28.69.134 with SMTP id l6mr606576wmi.80.1466471740272; Mon, 20 Jun 2016 18:15:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.167.22 with HTTP; Mon, 20 Jun 2016 18:15:39 -0700 (PDT) From: Martin Thomson Date: Tue, 21 Jun 2016 11:15:39 +1000 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Jun 2016 01:15:44 -0000 David Benjamin wrote our section on 0-RTT backward compatibility to be a little bit lenient about server deployment. On consideration, I think that a simpler set of rules are better: 1. If the server advertises support for 0-RTT, then it implies a commitment to support TLS 1.3 for the duration of that advertisement. 2. Therefore, if the client attempts 0-RTT, then it should reject a ServerHello with TLS 1.2 or older. https://github.com/tlswg/tls13-spec/pull/502 From nobody Mon Jun 20 18:42:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A433A12DAF5 for ; Mon, 20 Jun 2016 18:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3cS8M9UuV9P for ; Mon, 20 Jun 2016 18:42:32 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 2DDA312D58E for ; Mon, 20 Jun 2016 18:42:31 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id b72so1659704ywa.3 for ; Mon, 20 Jun 2016 18:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AjLyi910NeLAYWEzA8jmb+bxMRWYXxdh7OtatTNE4IU=; b=a3SDJIpGvRafetSYr7JaQgVCErU5osWT77YpSh82amDJtWxQKKzxx6VEWYqn1m1XDT hzqBWvAxcTqfYOZ9XME6sBRKyrtmvjdQ4sShqx+xCmjGaLiPIU6V2sD/Xg+aRZ46+TFN SyZOSGd13HqzwtTf717xK73y8uwZ2jXJUM0xedkw2FFpFRNQXHb0qWIkoubSzaRibxb8 gOdLjwQ52WKoEa3Kj84dqU+ONlNUYlk14GbWiBQ8ULL2+DzoKsA0wwz8D+BF42yxT+rj zHJcTZpEO946qe6vuSB2AWzJu30RPKmphy5hPnShM7L0o1WfW95bTs5YAYdJpDpoesqK txuA== 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; bh=AjLyi910NeLAYWEzA8jmb+bxMRWYXxdh7OtatTNE4IU=; b=glse3ktLHgDSr2EPuD8jABbIc+Tt5HMuvU0wUL2opoJyzBZeRMEn9ZAse3WOsqcb/n Z1D/+HZeyz2D1LsrN95jK2xnAkp+1ROwLJtKYhWD0YT5Tvu6XqtsPj3PXBaO2uDJocmi INj9C+WbqpqPZFSfKnr8OC5e/LecZTdiTtKbb6F+9xEw5oGKMCtMVmRg4KcjXUPv4dHe 7z+ZGmL6BS0a9ibLHDP7IRAg0uioBNqlQa4GzABdFYmmGW5aiu8sWTmLtD9HlFouUZYk oGC0/u5gIWcYXcN/pIT3W59gYL0nO8DE3cNRLBLBnH98aL09xhe3aFxzRgqA4ru1zWZE 2hoQ== X-Gm-Message-State: ALyK8tIV6/SKO0QSROKTy+OcH5Xhnhpff31Kd+PWUmMM79yooWNc0AJZvoLreZ0vOY+JraYeb6+GE5zjsHfUcA== X-Received: by 10.13.239.2 with SMTP id y2mr12211876ywe.22.1466473351028; Mon, 20 Jun 2016 18:42:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.105.193 with HTTP; Mon, 20 Jun 2016 18:42:29 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Mon, 20 Jun 2016 18:42:29 -0700 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c0350582958bd0535bfef68 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Jun 2016 01:42:33 -0000 --94eb2c0350582958bd0535bfef68 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 20, 2016 at 5:39 PM, Eric Rescorla wrote: > > 2. It's odd to just use a piece of the AEAD cipher (the encryption > function), especially if we ever had a really non-composite cipher. > This can be alleviated by using HKDF-Expand to produce the stream > of bits. > If we're going to use a non-standard construction, would it make more sense to "lose" the authentication on the inner layer? E.g., 1. Encrypt the content type with the "outer" key, 2. Encrypt the with the "inner" key using the same explicit IV. 3. Concatenate the cipher-texts of 1 and 2. 4. Compute an AAD tag/MAC across all of the data, using the "outer" key. In that scheme the content type or "outer" key authenticates all of the data, so you know it's tamper free. Still gross. -- Colm --94eb2c0350582958bd0535bfef68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 20, 2016 at 5:39 PM, Eric Rescorla <ekr@rtfm.com>= wrote:
2. It's odd to just use a= piece of the AEAD cipher (the encryption
function), especially i= f we ever had a really non-composite cipher.
This can be alleviat= ed by using HKDF-Expand to produce the stream
of bits.


If we're going to use = a non-standard construction, would it make more sense to "lose"= =C2=A0
the authentication on the inner layer?

E.g.,=C2=A0

1. Encrypt the content type with= the "outer" key,=C2=A0
2. Encrypt the with the "i= nner" key using the same explicit IV. =C2=A0
3. Concatenate = the cipher-texts =C2=A0of 1 and 2.=C2=A0
4. Compute an AAD tag/MA= C across all of the data, using the "outer" key.

In that scheme the content type or "outer" key authentic= ates all of the data, so you know it's tamper free. Still gross.=C2=A0<= /div>


--
Colm
--94eb2c0350582958bd0535bfef68-- From nobody Mon Jun 20 20:43:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DBA12D567 for ; Mon, 20 Jun 2016 20:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2DegU19IwiY for ; Mon, 20 Jun 2016 20:43:45 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002: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 53F3912D541 for ; Mon, 20 Jun 2016 20:43:45 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id l125so3375580ywb.2 for ; Mon, 20 Jun 2016 20:43:45 -0700 (PDT) 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-transfer-encoding:message-id; bh=FXErtFttsl/K7KjvGN+kUYSXGk+Sd9xtGXUjtkaPa0w=; b=iBPlaocL8+U8/OW6muyd7ruVg7GSJavW2PlY/s8tRIQI653UmqhDJvvXgqh1351NhP T3Uk0Lk6brV4qV82s0fqSxlqI3ynT1T+kuGuXHUm2F4xR/QgARA3V/oFb2qJp4akle51 wYUlXWbx1/ud01o0gYVSC8/8ZnEbV9yfjIW69Be5MUGvsoqagYvcJVT0q1jBuXPbmgr8 LxnL07ps69ikeXRdOX06um+Me4XcuDmQlT79WOqhkEWEvtWTVawGarfb6zJE6fNTZ+de N5ik/B660o3UGNegsS57+yZN+COddpGgy8D0oc7XzTKi8kTAvkoo61ZsNoqpmLuN491Z FiWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=FXErtFttsl/K7KjvGN+kUYSXGk+Sd9xtGXUjtkaPa0w=; b=IgeWPZmxCqQ5PtK88xbdzupYwuyF2ZFnvzKPZea6L30fGu43fS9ttUXzK9CdA6QAqc ooMxj6xNADhq9+We5kw9d1X40gfx7leMsNN9DqYgct4IdR0KQJGnwckRuqOH2msVmWaT BuYCziMmHF6Id+jfEC1PzKoc5KoU7//1pDu6mROysq8C7Y8uIIEgXMTfozZPODR6ujxq MI8kVgJfcs2QCpwgQPWTjfGEFP0qUX9ISPeIdyCh1M4y6t1ZmKlIu3GlTDwJj9bxJIFE 4Ljh5a5309CdMM8L+FOBxRloJSaaDHBNmqUzKwPUduEIAYru3EaKqo10I/YmXJQnsMTL 1o6w== X-Gm-Message-State: ALyK8tIBEK/7p4AI8tZ/vi9V/MqviK1L32rXE/ME9nIs3+AfqSI/V0+p9kwGA82hQKD8sQ== X-Received: by 10.129.48.147 with SMTP id w141mr10556513yww.266.1466480624419; Mon, 20 Jun 2016 20:43:44 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id f66sm16041392ywc.42.2016.06.20.20.43.43 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 20 Jun 2016 20:43:43 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Mon, 20 Jun 2016 23:43:41 -0400 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: <201606202343.42464.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Jun 2016 03:43:47 -0000 On Monday, June 20, 2016 08:39:11 pm Eric Rescorla wrote: > Nobody seems super-excited about either Option 1 or Option 2, so it's > at least worth noting that there's one of the options I claimed was > rejected earlier, namely separately encrypting the content type in > roughly the manner suggested by DKG, Ilari, and Kenny. Thanks for > Doug/Felix for prompting me on this. > > > NOTE: I don't promise any of the below is secure, though it probably > can be made so with enough work. Actually doing so is an exercise > for the reader. > > > The basic idea is as follows: > > 1. In each direction generate a separate "content_type_key" > 2. Separately encrypt the content type from the rest of the record > using the content_type_key. > 3. On the receiving side, first decrypt the content type and then use > that to determine what key to decrypt the record. > > The trivial version of this is just to AEAD encrypt the content type > separately, but this has unacceptable bandwidth and CPU properties, so > is probably not viable. However, there are more efficient designs, > which can get the overhead down to modest levels (<= 1 byte of > expansion and <=1/16 of a block computation/record). > > The obvious construction is to use the content_type_key to compute a > per-record masking value (effectively an ad hoc stream cipher) and > then use that to encrypt the content type (or potentially just a key > type bit) without integrity (though you might later protect it in the > additional data block under the main key). This gives you an > encryption function without expansion. If you have a mask function > which outputs one block at a time, you can use pieces of the block for > each record (e.g., for record N you use byte N/16) [1] > > > Obvious objections to this: > 1. This isn't integrity protected. This is probably the most serious > complaint and has the potential to actually leak information about > the content type unless you're careful [2], even if you eventually > integrity protect this information. > > 2. It's odd to just use a piece of the AEAD cipher (the encryption > function), especially if we ever had a really non-composite cipher. > This can be alleviated by using HKDF-Expand to produce the stream > of bits. > > 3. Maybe it doesn't get the whole job done, especially wrt the fact > that we're not rekeying the app data after client auth. > > 4. It's gross. Yes, yes it is. > > > I'm not really in love with this idea, but I did want people to know > that maybe we don't *have* to choose between option 1 and option 2 > in case that changes people's opinions. All this complexity for encrypting a single bit seems like way too much of a risk. An idea for an option 4: Keep typing and keying as it currently is (as of draft 13), but mandate a KeyUpdate immediately following (and/or before) non-application traffic. We already have a mechanism to use different keys in series, which sounds like it might be simpler than trying to figure out a good way to do so in parallel. Is this a viable thought to pursue, or does this still not help enough with our key separation worries? An additional thought might be adding a random to KeyUpdate to make the new key not based entirely on the old entropy. Dave From nobody Tue Jun 21 10:07:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573A512DB13 for ; Tue, 21 Jun 2016 10:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDN5ejuhYSkd for ; Tue, 21 Jun 2016 10:07:22 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010: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 CF51B12DB12 for ; Tue, 21 Jun 2016 10:07:21 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id l188so32754345lfe.2 for ; Tue, 21 Jun 2016 10:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OsamJCJip5VlACWdXgzOFzwUDoV9+BdYHfLbIJh7N8E=; b=Jtx0EUARIt5Q01NWasNyUWIhSaRdg1vr6d9pPZ/X7oJBPEYp+L/rs/oCZa1Am/S4YV oeTXs4z1Wzs2DFEzyy4SiwtQ9uxFiprKc1HJtIybdn0gsJXnYPtTo68ou5N17I45nhkQ pPaMvJXF8zPZMRfAPDUz+UZxJ5TNlCQjzLEl+mXGftU4W0L+6RNlua2ZaBMy2ad3uzC6 y3OmC+VrfxJEBTC/iS+HDGqVmnO9S8hp5IMTdiHBr9EgIv2ktE2l4dr8bidLdYLCECYg V7eKCAwbX0dOHhqBLQDwlPI7wopS4Oz7irOqmweUgB4TDsQRWfcsgdvK988+8jp3i0LB zmHg== 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; bh=OsamJCJip5VlACWdXgzOFzwUDoV9+BdYHfLbIJh7N8E=; b=F3X9LHWhkkAtp7fmsaU1LIFcd7XDnYXjr1IFx0UCzfmZAlYWNT8wDIizGsI77rN/cy /z8LmQ7DteWdv9Za25KPeyDDnqNQrLVInLl9vzu8zlLcNN0mf9WplHtMhZMkWdD8sdcx rdvkzxFkwG6PtOy3DFAqyyWZq6dhG0ffImcOWwTTn51NaV1Ap07N4UpEGBwRhJ6BOFQR Wj87tDktI1PUsCfWYXd+niv95j78BuS+ukLYXszigHplQXjIWRO6FdWcKdWsf7vcxA2Q ckaUV3UJoH/gcP2c8AmkCT6ofx8GNf0V2aeeqGggETAuq62rIJmjUYd5wjgnhH3yP0Sj fI3Q== X-Gm-Message-State: ALyK8tKNDWf/rRTQsQLu7YG4G4zvA9S2egX0DJx/fjT6glOZ/neFtQ/3EAaj+Qmi1xoimMAJMfhJhzCpS1mXUPb+ X-Received: by 10.28.168.86 with SMTP id r83mr4288708wme.44.1466528838549; Tue, 21 Jun 2016 10:07:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.29.14 with HTTP; Tue, 21 Jun 2016 10:07:17 -0700 (PDT) In-Reply-To: References: From: Ryan Hamilton Date: Tue, 21 Jun 2016 10:07:17 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114c08f479c7930535ccda03 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Jun 2016 17:07:23 -0000 --001a114c08f479c7930535ccda03 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 20, 2016 at 6:15 PM, Martin Thomson wrote: > David Benjamin wrote our section on 0-RTT backward compatibility to be > a little bit lenient about server deployment. On consideration, I > think that a simpler set of rules are better: > > 1. If the server advertises support for 0-RTT, then it implies a > commitment to support TLS 1.3 for the duration of that advertisement. > 2. Therefore, if the client attempts 0-RTT, then it should reject a > ServerHello with TLS 1.2 or older. > =E2=80=8BHow does this affect the situation where a server might attempt to= deploy TLS 1.3, discover a bug, and need to rollback? Does it just magically work?= =E2=80=8B --001a114c08f479c7930535ccda03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Jun 20, 2016 at 6:15 PM, Martin Thomson <m= artin.thomson@gmail.com> wrote:
David Benjamin = wrote our section on 0-RTT backward compatibility to be
a little bit lenient about server deployment.=C2=A0 On consideration, I
think that a simpler set of rules are better:

1. If the server advertises support for 0-RTT, then it implies a
commitment to support TLS 1.3 for the duration of that advertisement.
2. Therefore, if the client attempts 0-RTT, then it should reject a
ServerHello with TLS 1.2 or older.

=E2=80=8BHow does this affect the situation where a server might attemp= t to deploy TLS 1.3, discover a bug, and need to rollback? Does it just mag= ically work?=E2=80=8B

--001a114c08f479c7930535ccda03-- From nobody Tue Jun 21 10:46:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F95412DB67 for ; Tue, 21 Jun 2016 10:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUvwrGKqmXPt for ; Tue, 21 Jun 2016 10:46:54 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 873CD12DB60 for ; Tue, 21 Jun 2016 10:46:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 65BE54E25; Tue, 21 Jun 2016 20:46:51 +0300 (EEST) 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 ScnoYdfViP7l; Tue, 21 Jun 2016 20:46:51 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 194E0283; Tue, 21 Jun 2016 20:46:51 +0300 (EEST) Date: Tue, 21 Jun 2016 20:46:50 +0300 From: Ilari Liusvaara To: Dave Garrett Message-ID: <20160621174650.GA2989@LK-Perkele-V2.elisa-laajakaista.fi> References: <201606202343.42464.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201606202343.42464.davemgarrett@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Consensus call for keys used in handshake and data messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Jun 2016 17:46:56 -0000 On Mon, Jun 20, 2016 at 11:43:41PM -0400, Dave Garrett wrote: > > An idea for an option 4: Keep typing and keying as it currently is > (as of draft 13), but mandate a KeyUpdate immediately following > (and/or before) non-application traffic. We already have a mechanism > to use different keys in series, which sounds like it might be > simpler than trying to figure out a good way to do so in parallel. > > Is this a viable thought to pursue, or does this still not help >enough with our key separation worries? An additional thought > might be adding a random to KeyUpdate to make the new key not > based entirely on the old entropy. I don't think that would work. AFAIK, Basically using the appdata keys for anything else (and you do in the idea) breaks generic security. Of course, that generic security breaks does NOT imply that actual protocol security breaks, since for that one must actually make the actual protocol misuse the keys (and no reasonable way to do so is known for draft-13). And devising one seems very hard, since the operations you can try to misuse (and all are outside normal message space) are: - Rekey one direction of connection with a fresh key (key_update). - Request a certificate, send a certificate and proof of key holding (certificate_request, certificate, certificate_verify, finished) - Send a handle into separate dynamic PSK (new_session_ticket). And none of those seems to lend itself to misusing the key (the second has other known problems, but even fully separating the keys would not fix that). -Ilari From nobody Tue Jun 21 10:54:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97CAB12D74A for ; Tue, 21 Jun 2016 10:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4g086N8TnGyz for ; Tue, 21 Jun 2016 10:54:14 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD0012DB79 for ; Tue, 21 Jun 2016 10:54:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id BDBDC4EFE; Tue, 21 Jun 2016 20:54:13 +0300 (EEST) 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 rgbNbwHmyoSn; Tue, 21 Jun 2016 20:54:13 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 873622310; Tue, 21 Jun 2016 20:54:13 +0300 (EEST) Date: Tue, 21 Jun 2016 20:54:13 +0300 From: Ilari Liusvaara To: Ryan Hamilton Message-ID: <20160621175413.GB2989@LK-Perkele-V2.elisa-laajakaista.fi> References: 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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Jun 2016 17:54:15 -0000 On Tue, Jun 21, 2016 at 10:07:17AM -0700, Ryan Hamilton wrote: > On Mon, Jun 20, 2016 at 6:15 PM, Martin Thomson > wrote: > > > David Benjamin wrote our section on 0-RTT backward compatibility to be > > a little bit lenient about server deployment. On consideration, I > > think that a simpler set of rules are better: > > > > 1. If the server advertises support for 0-RTT, then it implies a > > commitment to support TLS 1.3 for the duration of that advertisement. > > 2. Therefore, if the client attempts 0-RTT, then it should reject a > > ServerHello with TLS 1.2 or older. > > > > ​How does this affect the situation where a server might attempt to deploy > TLS 1.3, discover a bug, and need to rollback? Does it just magically work?​ AFAIU, if one has 0-RTT-capable dynamic PSKs out there, one can only roll back 0-RTT support, but has to wait for all the PSKs to expire beefore being able to roll back TLS 1.3. Of course, the period between deploying TLS 1.3 and deploying 0-RTT should test how things work without 0-RTT (but it does not test 0-RTT failing, which is _critical_ to work correctly). -Ilari From nobody Tue Jun 21 11:45:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0013E12DC6F for ; Tue, 21 Jun 2016 11:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ed8hFsXBIxUl for ; Tue, 21 Jun 2016 11:45:24 -0700 (PDT) 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 7454112D8E6 for ; Tue, 21 Jun 2016 11:45:23 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id g13so17905202ioj.1 for ; Tue, 21 Jun 2016 11:45:23 -0700 (PDT) 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 :cc; bh=IeqyJuSr1Cs5W3egxGBnSF8NrFjJHdSxvDjfV/72tz8=; b=WUOyXPuZmyWBf+mH3hcb/4nC2/TCRp59EeMUPUDI0qpZvqlzgpvDVeUzL2TWtXnqzH x82EzNyPmD9tPw7fcjf2+b6k3F1ZJ1BAK66IfgPp2qmRgNAcMZRbYziaoWiOX9dRwhvZ 5zsCHn7WB0JwkG852dJ3BuWgKbNnmJJ9pKT5w= 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:cc; bh=IeqyJuSr1Cs5W3egxGBnSF8NrFjJHdSxvDjfV/72tz8=; b=ZvmtaQwqB0R5XJDT3YhzQGnD2pouv8WD8NXUqFtsPcyL0YauNvXDsZ4gecRZOI0y4B 5+oZxeHo9NGfLTsqwzSqoYPg5ALJ41LIwcn3+USA3mxuOg9pHT1muVR7Koc9yZgE+jam 8v6QsKKbNReB20VJsh+H2/hHkHQ38qU0yVcxaDlmviHq2edREX31HZ/n/VR4dShgg3X6 Sn5P7Buv68sQ/7F0nZY2PcrjAURDq9eHIGxIGtgIVsRfs1O0z88SuUxdyioJGLq9hNkM p/x3WfFoj2g5NoHe1gsJDe+BR8YifW0N0Tn9Wh7QLOMlX64x/5HLU6Go/n6v/uHDQxEy pvrw== X-Gm-Message-State: ALyK8tJHTaKQRT0m680gnn+JQ1lXCAazok42E6AwZ6hYt+ixgm34FsSmv+gAMLL49XkEpXmSC5+oApzJDx7EPQUB X-Received: by 10.107.29.80 with SMTP id d77mr36714592iod.97.1466534722625; Tue, 21 Jun 2016 11:45:22 -0700 (PDT) MIME-Version: 1.0 References: <20160621175413.GB2989@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160621175413.GB2989@LK-Perkele-V2.elisa-laajakaista.fi> From: David Benjamin Date: Tue, 21 Jun 2016 18:45:12 +0000 Message-ID: To: Ilari Liusvaara , Ryan Hamilton Content-Type: multipart/alternative; boundary=001a11408bf231d2d80535ce3977 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Jun 2016 18:45:27 -0000 --001a11408bf231d2d80535ce3977 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 21, 2016 at 1:54 PM Ilari Liusvaara wrote: > On Tue, Jun 21, 2016 at 10:07:17AM -0700, Ryan Hamilton wrote: > > On Mon, Jun 20, 2016 at 6:15 PM, Martin Thomson < > martin.thomson@gmail.com> > > wrote: > > > > > David Benjamin wrote our section on 0-RTT backward compatibility to b= e > > > a little bit lenient about server deployment. On consideration, I > > > think that a simpler set of rules are better: > > > > > > 1. If the server advertises support for 0-RTT, then it implies a > > > commitment to support TLS 1.3 for the duration of that advertisement. > > > 2. Therefore, if the client attempts 0-RTT, then it should reject a > > > ServerHello with TLS 1.2 or older. > > > > > > > =E2=80=8BHow does this affect the situation where a server might attemp= t to > deploy > > TLS 1.3, discover a bug, and need to rollback? Does it just magically > work?=E2=80=8B > > AFAIU, if one has 0-RTT-capable dynamic PSKs out there, one can only roll > back 0-RTT support, but has to wait for all the PSKs to expire beefore > being able to roll back TLS 1.3. > > Of course, the period between deploying TLS 1.3 and deploying 0-RTT > should test how things work without 0-RTT (but it does not test 0-RTT > failing, which is _critical_ to work correctly). > Right, this is the deployment complexity I was hoping to avoid with the section. I expect that large companies with TLS experts on staff will be able to navigate this difficulty. We can deploy TLS 1.3, wait for everything to stick, and then turn on 0-RTT. But smaller and medium-size deployments may simply have a handful of stock installs of their favorite operating system and server software. People like things being fast, so either 0-RTT will be on by default on web servers or people will copy-and-paste config options. It's those deployments which I don't expect to get this right. This isn't a theoretical concern. OpenSSL and very early revisions of BoringSSL had a bug around session handling with similar effects. If one established a TLS 1.2 session and then later did a full TLS 1.0 handshake, even though the TLS 1.2 session was *not* resumed, merely offering it caused OpenSSL to lock the version. Very early on in switching Chrome from NSS to BoringSSL, we hit interoperability issues due to this. https://www.debian.org, at the time, had a heterogeneous deployment of TLS 1.0 and 1.2. This was rather messy to diagnose. Flaky failures are the worst. I can also imagine this sort of thing happening if users turn antivirus products with TLS MITMs on and off, or if they have a work machine with a TLS MITM certificate and enter/leave their networks. (I'm sure no one on this list, myself included, has any love for this sort of configuration, but it is reality.) David --001a11408bf231d2d80535ce3977 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 21= , 2016 at 1:54 PM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Tue, Jun 21, 2016 at 10:07:17AM -0700, Ryan Hamilton wrote= :
> On Mon, Jun 20, 2016 at 6:15 PM, Martin Thomson <martin.thomson@gmail.com>= ;
> wrote:
>
> > David Benjamin wrote our section on 0-RTT backward compatibility = to be
> > a little bit lenient about server deployment.=C2=A0 On considerat= ion, I
> > think that a simpler set of rules are better:
> >
> > 1. If the server advertises support for 0-RTT, then it implies a<= br> > > commitment to support TLS 1.3 for the duration of that advertisem= ent.
> > 2. Therefore, if the client attempts 0-RTT, then it should reject= a
> > ServerHello with TLS 1.2 or older.
> >
>
> =E2=80=8BHow does this affect the situation where a server might attem= pt to deploy
> TLS 1.3, discover a bug, and need to rollback? Does it just magically = work?=E2=80=8B

AFAIU, if one has 0-RTT-capable dynamic PSKs out there, one can only roll back 0-RTT support, but has to wait for all the PSKs to expire beefore
being able to roll back TLS 1.3.

Of course, the period between deploying TLS 1.3 and deploying 0-RTT
should test how things work without 0-RTT (but it does not test 0-RTT
failing, which is _critical_ to work correctly).

<= /div>
Right, this is the deployment complexity I was hoping to avoid wi= th the section. I expect that large companies with TLS experts on staff wil= l be able to navigate this difficulty. We can deploy TLS 1.3, wait for ever= ything to stick, and then turn on 0-RTT.

But small= er and medium-size deployments may simply have a handful of stock installs = of their favorite operating system and server software. People like things = being fast, so either 0-RTT will be on by default on web servers or people = will copy-and-paste config options. It's those deployments which I don&= #39;t expect to get this right.

This isn't a t= heoretical concern. OpenSSL and very early revisions of BoringSSL had a bug= around session handling with similar effects. If one established a TLS 1.2= session and then later did a full TLS 1.0 handshake, even though the TLS 1= .2 session was *not* resumed, merely offering it caused OpenSSL to lock the= version. Very early on in switching Chrome from NSS to BoringSSL, we hit i= nteroperability issues due to this. http= s://www.debian.org, at the time, had a heterogeneous deployment of TLS = 1.0 and 1.2. This was rather messy to diagnose. Flaky failures are the wors= t.

I can also imagine this sort of thing happening= if users turn antivirus products with TLS MITMs on and off, or if they hav= e a work machine with a TLS MITM certificate and enter/leave their networks= . (I'm sure no one on this list, myself included, has any love for this= sort of configuration, but it is reality.)

Da= vid
--001a11408bf231d2d80535ce3977-- From nobody Tue Jun 21 17:24:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7335212DAAC for ; Tue, 21 Jun 2016 17:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0O0ed92dNS4E for ; Tue, 21 Jun 2016 17:24:38 -0700 (PDT) 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 AF78D12DA71 for ; Tue, 21 Jun 2016 17:24:32 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id h129so50548871lfh.1 for ; Tue, 21 Jun 2016 17:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kaOPQVahhAr5VvLJZ0OA7+D4M0gkHwIRqwoctWEsrgs=; b=Hhw+reYNDA6ZanpGlJBZHKIRk6XMdvc4QUMD9COShuPQMIyxgGHivtUsrxCf5qdKl4 n6Xj3oRU/2m13K1AleqLpKlcw+CwhCCa+S9JmNvYCu9yWsPADc/zyFRc3uEumNFsSBSG DdbKdCWPXQaIGItI9SnTRWDNA/OJ9EhIoiqvN8ikZCI7OOrIrZ8Cldjb5DismeYCrAqb lCrVioCWuDjWVJGuDfmL/0RcbAwNkciswAELgjJO5S4+B4UY0s7hQpq9Ol9s7EXUqFU1 MaPfdn1mL1TwktG+e+RpMBB/HYHKw47e1rdYeTZSHluqlagh8uNmNkg5NhNrf/riChaB o4EQ== 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; bh=kaOPQVahhAr5VvLJZ0OA7+D4M0gkHwIRqwoctWEsrgs=; b=EExXC4s1e6MfL/habP945tgUJINH3j01C7ujaLBXDgaLhtjHNOWHyx60cHjiMRA1Om UXcdJqT8AiuFbheEKlJZ6/IdrGHOx4584/k8+noy5HgVH8S2AnTb5/tCyzgkSdfLZkId hLRb0rjf/IiHmL4f4fNwVqyXngf/OwoAAuN7V18b/oTJrcAxgDohPqAKsBYHRsRjexOG u7tlldfh5eXRThvcLKPm/NQlWibAM1zFZSSPEX2np3F8LIhOs6WXMPFYjZC0ofznHM7j LNlljgCnh03SdJdPpQYAdxOHkyt7btUGtTxJUDMNajUSAgpk6UilKILT2llzfTHPWg7E 0Vbg== X-Gm-Message-State: ALyK8tJkFV4ojJqZY3VMLOOlQSoX5aUFpZIwnateRRMzWpGKpB98+fiWjRr6utoSU8YOIdlf9j5mQw9iBjjqog== X-Received: by 10.28.18.199 with SMTP id 190mr5598888wms.66.1466555070884; Tue, 21 Jun 2016 17:24:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.167.22 with HTTP; Tue, 21 Jun 2016 17:24:30 -0700 (PDT) In-Reply-To: References: <20160621175413.GB2989@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Wed, 22 Jun 2016 10:24:30 +1000 Message-ID: To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 Jun 2016 00:24:39 -0000 To be clear about this, I expect that browsers will do some fairly horrific things in response to this. We will attempt to use 0-RTT, get TLS 1.2 and abort as described. But then we will do the shameful thing and fall back to 1.2. Plotting out the alternatives, I don't really see a better option. On 22 June 2016 at 04:45, David Benjamin wrote: > On Tue, Jun 21, 2016 at 1:54 PM Ilari Liusvaara > wrote: >> >> On Tue, Jun 21, 2016 at 10:07:17AM -0700, Ryan Hamilton wrote: >> > On Mon, Jun 20, 2016 at 6:15 PM, Martin Thomson >> > >> > wrote: >> > >> > > David Benjamin wrote our section on 0-RTT backward compatibility to be >> > > a little bit lenient about server deployment. On consideration, I >> > > think that a simpler set of rules are better: >> > > >> > > 1. If the server advertises support for 0-RTT, then it implies a >> > > commitment to support TLS 1.3 for the duration of that advertisement. >> > > 2. Therefore, if the client attempts 0-RTT, then it should reject a >> > > ServerHello with TLS 1.2 or older. >> > > >> > >> > How does this affect the situation where a server might attempt to >> > deploy >> > TLS 1.3, discover a bug, and need to rollback? Does it just magically >> > work? >> >> AFAIU, if one has 0-RTT-capable dynamic PSKs out there, one can only roll >> back 0-RTT support, but has to wait for all the PSKs to expire beefore >> being able to roll back TLS 1.3. >> >> Of course, the period between deploying TLS 1.3 and deploying 0-RTT >> should test how things work without 0-RTT (but it does not test 0-RTT >> failing, which is _critical_ to work correctly). > > > Right, this is the deployment complexity I was hoping to avoid with the > section. I expect that large companies with TLS experts on staff will be > able to navigate this difficulty. We can deploy TLS 1.3, wait for everything > to stick, and then turn on 0-RTT. > > But smaller and medium-size deployments may simply have a handful of stock > installs of their favorite operating system and server software. People like > things being fast, so either 0-RTT will be on by default on web servers or > people will copy-and-paste config options. It's those deployments which I > don't expect to get this right. > > This isn't a theoretical concern. OpenSSL and very early revisions of > BoringSSL had a bug around session handling with similar effects. If one > established a TLS 1.2 session and then later did a full TLS 1.0 handshake, > even though the TLS 1.2 session was *not* resumed, merely offering it caused > OpenSSL to lock the version. Very early on in switching Chrome from NSS to > BoringSSL, we hit interoperability issues due to this. > https://www.debian.org, at the time, had a heterogeneous deployment of TLS > 1.0 and 1.2. This was rather messy to diagnose. Flaky failures are the > worst. > > I can also imagine this sort of thing happening if users turn antivirus > products with TLS MITMs on and off, or if they have a work machine with a > TLS MITM certificate and enter/leave their networks. (I'm sure no one on > this list, myself included, has any love for this sort of configuration, but > it is reality.) > > David > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Jun 21 17:27:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7FD12D868 for ; Tue, 21 Jun 2016 17:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3pv0Z63cHQG for ; Tue, 21 Jun 2016 17:27:17 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 CB56B12D0CB for ; Tue, 21 Jun 2016 17:27:16 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id u64so42212487vkf.3 for ; Tue, 21 Jun 2016 17:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=MjqS+l5woymZZ2rTGSnXh4LS0klUIiWmcxk8Srpg0w8=; b=X9p1/o5rSTafxKBVGDJHkkBvfL5tdrYRQxY1IrlToWllithN9Qc8CD3veT5o4aQ++K XIRj6y/b1LIRmHRFceiEs+gciBHUPJxoMSu/hzYxPdeRl9ZyUIPVJGkji/NQQi5s/5Pg NRlNM13E++Xg+REc75JvbV0Om8XehweAF2YonlLMGjnZzQN5PdOlmnu6m92EZmAyBiKc ptnH2RHZhAqZIbRLicbKhS+XFALJOEBGf3yfjeSKoffK3X0UTD1E3+evKxxt9zqXj+mi v0vWtLzG+Gnk4JX+fe+DM/H8++s0avaqCSQxMmw3dhPhx+vRECnFsmcNKtf8EO8o7VlR 2Mqw== 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; bh=MjqS+l5woymZZ2rTGSnXh4LS0klUIiWmcxk8Srpg0w8=; b=E3cM/zj+JDgCthcwGVdVDtZfXuj0lxm3hZ9G8Fji7e5RaRqOs/fE2DwXbwNVdD+Omq 25mSAc9lKVR5RRFv/o0MV4bsaE01O+0aS4kizrnm12zTwCKsQcHsUhzGd9G7fHCi+/UU nOk8DL+6xGjqJXxeiow6NkKtRzh4zfOeRFw25ASgcoCSzTe9BF2O2DmaOJdNdJ1T67VL 7dncqPQ6i736i3MKluvFG2KtGU7hCIPdFQB2hxXi6DF0QTOM7K41W3e4Xyny/k09UvHg 4APQdBYNolSo1L6Fw/WZdAUzdALkUCBIIwRnD5Iypytk6CAm58wYxWNH/pGVMct77Z3l NEXw== X-Gm-Message-State: ALyK8tJyjWaNXyzuh+QKOE8qXm6ka1Csgb9xekKyAqON1NM7/tvv32NYzg5iCFc5jrryA1NSyU7oP8Bq0Y5wTQ== MIME-Version: 1.0 X-Received: by 10.159.37.66 with SMTP id 60mr8841752uaz.56.1466555235444; Tue, 21 Jun 2016 17:27:15 -0700 (PDT) Received: by 10.159.35.78 with HTTP; Tue, 21 Jun 2016 17:27:14 -0700 (PDT) Received: by 10.159.35.78 with HTTP; Tue, 21 Jun 2016 17:27:14 -0700 (PDT) In-Reply-To: References: <20160621175413.GB2989@LK-Perkele-V2.elisa-laajakaista.fi> Date: Tue, 21 Jun 2016 17:27:14 -0700 Message-ID: From: Watson Ladd To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c124170da30040535d2ff3e Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 Jun 2016 00:27:19 -0000 --94eb2c124170da30040535d2ff3e Content-Type: text/plain; charset=UTF-8 On Jun 21, 2016 5:25 PM, "Martin Thomson" wrote: > > To be clear about this, I expect that browsers will do some fairly > horrific things in response to this. We will attempt to use 0-RTT, > get TLS 1.2 and abort as described. Isn't 0-RTT refusable? Why not treat 1.2 negotiation as a refusal? > > But then we will do the shameful thing and fall back to 1.2. Plotting > out the alternatives, I don't really see a better option. > > On 22 June 2016 at 04:45, David Benjamin wrote: > > On Tue, Jun 21, 2016 at 1:54 PM Ilari Liusvaara < ilariliusvaara@welho.com> > > wrote: > >> > >> On Tue, Jun 21, 2016 at 10:07:17AM -0700, Ryan Hamilton wrote: > >> > On Mon, Jun 20, 2016 at 6:15 PM, Martin Thomson > >> > > >> > wrote: > >> > > >> > > David Benjamin wrote our section on 0-RTT backward compatibility to be > >> > > a little bit lenient about server deployment. On consideration, I > >> > > think that a simpler set of rules are better: > >> > > > >> > > 1. If the server advertises support for 0-RTT, then it implies a > >> > > commitment to support TLS 1.3 for the duration of that advertisement. > >> > > 2. Therefore, if the client attempts 0-RTT, then it should reject a > >> > > ServerHello with TLS 1.2 or older. > >> > > > >> > > >> > How does this affect the situation where a server might attempt to > >> > deploy > >> > TLS 1.3, discover a bug, and need to rollback? Does it just magically > >> > work? > >> > >> AFAIU, if one has 0-RTT-capable dynamic PSKs out there, one can only roll > >> back 0-RTT support, but has to wait for all the PSKs to expire beefore > >> being able to roll back TLS 1.3. > >> > >> Of course, the period between deploying TLS 1.3 and deploying 0-RTT > >> should test how things work without 0-RTT (but it does not test 0-RTT > >> failing, which is _critical_ to work correctly). > > > > > > Right, this is the deployment complexity I was hoping to avoid with the > > section. I expect that large companies with TLS experts on staff will be > > able to navigate this difficulty. We can deploy TLS 1.3, wait for everything > > to stick, and then turn on 0-RTT. > > > > But smaller and medium-size deployments may simply have a handful of stock > > installs of their favorite operating system and server software. People like > > things being fast, so either 0-RTT will be on by default on web servers or > > people will copy-and-paste config options. It's those deployments which I > > don't expect to get this right. > > > > This isn't a theoretical concern. OpenSSL and very early revisions of > > BoringSSL had a bug around session handling with similar effects. If one > > established a TLS 1.2 session and then later did a full TLS 1.0 handshake, > > even though the TLS 1.2 session was *not* resumed, merely offering it caused > > OpenSSL to lock the version. Very early on in switching Chrome from NSS to > > BoringSSL, we hit interoperability issues due to this. > > https://www.debian.org, at the time, had a heterogeneous deployment of TLS > > 1.0 and 1.2. This was rather messy to diagnose. Flaky failures are the > > worst. > > > > I can also imagine this sort of thing happening if users turn antivirus > > products with TLS MITMs on and off, or if they have a work machine with a > > TLS MITM certificate and enter/leave their networks. (I'm sure no one on > > this list, myself included, has any love for this sort of configuration, but > > it is reality.) > > > > David > > > > _______________________________________________ > > 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 --94eb2c124170da30040535d2ff3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 21, 2016 5:25 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>
> To be clear about this, I expect that browsers will do some fairly
> horrific things in response to this.=C2=A0 We will attempt to use 0-RT= T,
> get TLS 1.2 and abort as described.

Isn't 0-RTT refusable? Why not treat 1.2 negotiation as = a refusal?
>
> But then we will do the shameful thing and fall back to 1.2.=C2=A0 Plo= tting
> out the alternatives, I don't really see a better option.
>
> On 22 June 2016 at 04:45, David Benjamin <davidben@chromium.org> wrote:
> > On Tue, Jun 21, 2016 at 1:54 PM Ilari Liusvaara <ilariliusvaara@welho.com>
> > wrote:
> >>
> >> On Tue, Jun 21, 2016 at 10:07:17AM -0700, Ryan Hamilton wrote= :
> >> > On Mon, Jun 20, 2016 at 6:15 PM, Martin Thomson
> >> > <martin.t= homson@gmail.com>
> >> > wrote:
> >> >
> >> > > David Benjamin wrote our section on 0-RTT backward = compatibility to be
> >> > > a little bit lenient about server deployment.=C2=A0= On consideration, I
> >> > > think that a simpler set of rules are better:
> >> > >
> >> > > 1. If the server advertises support for 0-RTT, then= it implies a
> >> > > commitment to support TLS 1.3 for the duration of t= hat advertisement.
> >> > > 2. Therefore, if the client attempts 0-RTT, then it= should reject a
> >> > > ServerHello with TLS 1.2 or older.
> >> > >
> >> >
> >> > How does this affect the situation where a server might = attempt to
> >> > deploy
> >> > TLS 1.3, discover a bug, and need to rollback? Does it j= ust magically
> >> > work?
> >>
> >> AFAIU, if one has 0-RTT-capable dynamic PSKs out there, one c= an only roll
> >> back 0-RTT support, but has to wait for all the PSKs to expir= e beefore
> >> being able to roll back TLS 1.3.
> >>
> >> Of course, the period between deploying TLS 1.3 and deploying= 0-RTT
> >> should test how things work without 0-RTT (but it does not te= st 0-RTT
> >> failing, which is _critical_ to work correctly).
> >
> >
> > Right, this is the deployment complexity I was hoping to avoid wi= th the
> > section. I expect that large companies with TLS experts on staff = will be
> > able to navigate this difficulty. We can deploy TLS 1.3, wait for= everything
> > to stick, and then turn on 0-RTT.
> >
> > But smaller and medium-size deployments may simply have a handful= of stock
> > installs of their favorite operating system and server software. = People like
> > things being fast, so either 0-RTT will be on by default on web s= ervers or
> > people will copy-and-paste config options. It's those deploym= ents which I
> > don't expect to get this right.
> >
> > This isn't a theoretical concern. OpenSSL and very early revi= sions of
> > BoringSSL had a bug around session handling with similar effects.= If one
> > established a TLS 1.2 session and then later did a full TLS 1.0 h= andshake,
> > even though the TLS 1.2 session was *not* resumed, merely offerin= g it caused
> > OpenSSL to lock the version. Very early on in switching Chrome fr= om NSS to
> > BoringSSL, we hit interoperability issues due to this.
> > https://www.debian.org, at= the time, had a heterogeneous deployment of TLS
> > 1.0 and 1.2. This was rather messy to diagnose. Flaky failures ar= e the
> > worst.
> >
> > I can also imagine this sort of thing happening if users turn ant= ivirus
> > products with TLS MITMs on and off, or if they have a work machin= e with a
> > TLS MITM certificate and enter/leave their networks. (I'm sur= e no one on
> > this list, myself included, has any love for this sort of configu= ration, but
> > it is reality.)
> >
> > David
> >
> > _______________________________________________
> > 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

--94eb2c124170da30040535d2ff3e-- From nobody Tue Jun 21 17:30:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277BA12D0CB for ; Tue, 21 Jun 2016 17:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duD_IXD3ktyh for ; Tue, 21 Jun 2016 17:30:31 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9F97A12DEC0 for ; Tue, 21 Jun 2016 17:30:31 -0700 (PDT) Received: from [173.75.83.83] (helo=Williams-MacBook-Pro.local) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1bFW3j-0001pC-JN; Tue, 21 Jun 2016 20:30:23 -0400 Date: Tue, 21 Jun 2016 17:30:21 -0700 From: Bill Frantz To: Martin Thomson X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec792ea245ff6d920439636935205e3aefa2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.83 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 Jun 2016 00:30:33 -0000 On 6/22/16 at 5:24 PM, martin.thomson@gmail.com (Martin Thomson) wrote: >To be clear about this, I expect that browsers will do some fairly >horrific things in response to this. We will attempt to use 0-RTT, >get TLS 1.2 and abort as described. > >But then we will do the shameful thing and fall back to 1.2. Plotting >out the alternatives, I don't really see a better option. Well, it seems like a browser could try TLS 1.3 without 0-RTT first. If it connects with 1.3 non-0-RTT, then it could mark the host=20 as not supporting 0-RTT for a day or so and after that time=20 retry to see if the host has been fixed. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Since the IBM Selectric, keyboards have gotten 408-356-8506 | steadily worse. Now we have touchscreen keyboards. www.pwpconsult.com | Can we make something even worse? From nobody Tue Jun 21 17:44:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A67112D0CB for ; Tue, 21 Jun 2016 17:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fi4Q9gXLJpWS for ; Tue, 21 Jun 2016 17:44:03 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010: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 0C05B12D755 for ; Tue, 21 Jun 2016 17:44:03 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id f6so50655956lfg.0 for ; Tue, 21 Jun 2016 17:44:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gF+n1cLlBRkWjXTfL6ZnXpCrhfh2GvvJIH1kpnq+gRA=; b=kJ1pjg7SlILCqcQ3UVoQNoE+S7s+htIFbD/5g8vOlaTqQ7BQgP483UWriG5xNY0CAb UyZ1XDBSTHN+Z4pNfruTC3oQNy+NoMMjw4q8LOhPuypkj6GdoQWkTS71BtbTHl3BBQfL S8esKQC4+BGgi2g/VqF9hGSAny5Uflsvx2XMGurAU2hQQmMoDMO0EyxBtCmAzvNeaMdZ 3ZZM307/sRipFoF9A0/iRsh4hIlCf4Sr5cRpfGUwX2APZ8J/X0WTkhxB9H6xh/A2Sa0A XMpDDlmaBReiFJuZvFGaxzDxe59v2V90JO5A4LGOBX8wpvRzPhdhKgBvSMCZPMussn4o VG/Q== 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; bh=gF+n1cLlBRkWjXTfL6ZnXpCrhfh2GvvJIH1kpnq+gRA=; b=KlTL4s5g2k2sAD2d6WQ2CZ0YFlQHoVFhyf5u/46iUpHaxFPckjczMztztpxh5mXQDg P6QRvNUMtubCb3+1ijKTQ1bP+KVKh7xSormVMiWLh9XlpaVH1TFcHv2MX2Ym2cqjfCDZ T2xoUXyVn5yxhaAf+ClgSUmJRgWb3oNSHadSFT3uaAq3hwQ6EmyJUcC339jbdP3ZpWat 4pixyhF5OUqRFAdbYsR8nJfSVwIQySGtmgO5ZbDVX368rXgNGLZgXkIzlK1h44CHqOHz 3bf6Y6kQQceI+i5ZQkf6YZ5QraDl1Mro6Crx9BJHLma8s7s/cBv8/6g4lYIOKiKxygH8 GS3g== X-Gm-Message-State: ALyK8tKsDW0K9qOo00Q93VudJQwv6Jp/URSIm0sAd51glelS35zumRByW+9CUUozsrQ1vPdsSfx9K8MI6h0TDw== X-Received: by 10.194.167.39 with SMTP id zl7mr22460736wjb.98.1466556241277; Tue, 21 Jun 2016 17:44:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.167.22 with HTTP; Tue, 21 Jun 2016 17:44:00 -0700 (PDT) In-Reply-To: References: <20160621175413.GB2989@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Wed, 22 Jun 2016 10:44:00 +1000 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 Jun 2016 00:44:05 -0000 On 22 June 2016 at 10:27, Watson Ladd wrote: > Isn't 0-RTT refusable? Why not treat 1.2 negotiation as a refusal? The problem isn't that you get a 1.2 ServerHello, it's what happens after that. The server is going to choke on your 0-RTT data when it receives that instead of the client's second flight. If it doesn't, it's probably passing your 0-RTT ciphertext to the application as plaintext and that's even worse. I don't expect people to update their 1.2 implementations to be able to ignore 0-RTT data. From nobody Tue Jun 21 17:45:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E5912DEBD for ; Tue, 21 Jun 2016 17:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vftTuRKpfW2s for ; Tue, 21 Jun 2016 17:45:16 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010: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 E567912D755 for ; Tue, 21 Jun 2016 17:45:15 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id f6so50687986lfg.0 for ; Tue, 21 Jun 2016 17:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3cYdiK+k+9/L5UGI2TPb+aABV/z/qTg25KoZ6BskQQk=; b=uAN9BfYLZ6PNHGOnLYEPr4smefxkUMxB5yAdKmbe/YZZzOdZDaGeGMTldotDfQX9Ta KqtCMob6FKmiETtAGS267nP6Z+2rVJghpuYs94oGIv/LVbcQT6t36IC6FPPFeJi1tjtS TJle/XG+gfZX1DGaj1uGTBh/2emHeWXc1txr6j6EKmm6pebtEuLI6e9CtfaXVCC9PgXQ OK2r1rrg2Eaymtf77ZAuRYDFbOjAUz5RKhryny54TPhiMwYEO3rrpKmaTBGGpddRSJtp 4pa+OC4nHfk8lgfqL7T+D3XorkBa8ZWNTpTRUF5HUd+oyY4JrAU7GtRXTf2LT7o5jU9e LMQA== 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; bh=3cYdiK+k+9/L5UGI2TPb+aABV/z/qTg25KoZ6BskQQk=; b=TGO5ezCtYqkEJls2Iy/h11t1ggKcKq9dOiESkHxiqdoyVsUFZGwqkHeAfxEwKdLqHW GXp0GNrfW+hjxtIZpYGICpTDH25Wji5TP31FTb/9U7x4qMWK6ye86lGNgK371JtpDGZZ FJ3GZUczh5Mk3NDiitngBMvwHrXBt+497lghltsEjmqSqOfeYBBLskhLzewIfDr9I+O1 WKGkz/ln+a9PJiu8B2fsOkJ6HLzOL/dEYznsoIsbw5F5UGCnFpdMyY/+nJiRpOzOLIBo 5ixvjmLhWuErIQpZaEEUV8QJqSt3+76WqvdRHgsxlnHf6Jaeuv2qWDHXB2FR9Jhr4l2e bXqw== X-Gm-Message-State: ALyK8tINoMWZ+fefJ6yTYYDgHjtrk2HsPujtVr1h5x5Cz3kevn5lc6zgcX6KyIoxhDt4iGLwizzXWdWukzoMsA== X-Received: by 10.194.68.4 with SMTP id r4mr21662807wjt.77.1466556313913; Tue, 21 Jun 2016 17:45:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.167.22 with HTTP; Tue, 21 Jun 2016 17:45:13 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 22 Jun 2016 10:45:13 +1000 Message-ID: To: Bill Frantz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 Jun 2016 00:45:17 -0000 On 22 June 2016 at 10:30, Bill Frantz wrote: > Well, it seems like a browser could try TLS 1.3 without 0-RTT first. > > If it connects with 1.3 non-0-RTT, then it could mark the host as not > supporting 0-RTT for a day or so and after that time retry to see if the > host has been fixed. Yes, that is an option. Harder to manage, but certainly possible and (overall) preferable to falling back to 1.2. From nobody Tue Jun 21 19:01:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87CD812DF08 for ; Tue, 21 Jun 2016 19:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAQbasteoKyL for ; Tue, 21 Jun 2016 19:01:21 -0700 (PDT) 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 39ADF12DF06 for ; Tue, 21 Jun 2016 19:01:21 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id u64so44183362vkf.3 for ; Tue, 21 Jun 2016 19:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=9ukv2xY2tFmSrj1DgTg4AqumYuLQpsGz3eV93Urnuwg=; b=wYEakIdUpPg0Ge9dLkG5bCGKG98zeOebkh5o02yLmwqpjQ4vffJSqNb8kL5zqcl3Mr t1PR3Mx+hj1ZPOMVdgleY2khPf5aSFjaJgDRIt/smGs9iOsRUiJl1vb3G93gEtPooux9 BhnRV+i/a7ucq4qmsV047k1Y6MwzE4K9B03uZHa4ZHpyqrEdNcakhxJ3WrXYR3nxt1ZR oCotDWYdTWF+N3RLFYi3N7zAQII+FTX7FgYTCdpRXRQXxhdXVmgtxdXsiS8TYOX/rRaL XmBO+J6cDeeYg9Rwl5x5kqiukA8Ku4HaieaIsO7Ofyotslg7mf0ekGwKT4OTM4KqGPif W9aQ== 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; bh=9ukv2xY2tFmSrj1DgTg4AqumYuLQpsGz3eV93Urnuwg=; b=AJVFGnzhM5JG1vcTe9vBiWYvdhN3y91bHrACy3hKB9dZm652YpxRX1mYM59DHvcN1m EFb6QpFGMUsmdeTU5g284f1HJsiOAMpSVTXwWS9sZ7DrDa0Qb/bRnb5w/1kX9LxB5ErH PSKPI0IpMXqxz4emDtDbU1/EmafoMdY/s3X9K2fDAIYLpnh1g9asw1+WcmgKT4OVMN3s mxwHVqHgSI6rQSQHCU94CAtJXC8MlgWDbSky6BR1oZbhY5RhruCCcXlvb75xwGfTYvYd JtE47fg8mC30yOp2mqdVSHO5/rW0GNfP8PO+5uLBD5nlnkc8cetrxV1di717ZSFu/F+P 1oNg== X-Gm-Message-State: ALyK8tJIIjxxOqd6tXev64Wf0f0JzebKeREB2/2f9KSGC4GiBRatBiXxIUTFoK2rq6lctKwxWmvnw04KmXkA0w== MIME-Version: 1.0 X-Received: by 10.176.0.56 with SMTP id 53mr10953973uai.87.1466560879841; Tue, 21 Jun 2016 19:01:19 -0700 (PDT) Received: by 10.159.35.78 with HTTP; Tue, 21 Jun 2016 19:01:19 -0700 (PDT) Received: by 10.159.35.78 with HTTP; Tue, 21 Jun 2016 19:01:19 -0700 (PDT) In-Reply-To: References: <20160621175413.GB2989@LK-Perkele-V2.elisa-laajakaista.fi> Date: Tue, 21 Jun 2016 19:01:19 -0700 Message-ID: From: Watson Ladd To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113db6da48d9630535d45026 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 Jun 2016 02:01:22 -0000 --001a113db6da48d9630535d45026 Content-Type: text/plain; charset=UTF-8 On Jun 21, 2016 5:44 PM, "Martin Thomson" wrote: > > On 22 June 2016 at 10:27, Watson Ladd wrote: > > Isn't 0-RTT refusable? Why not treat 1.2 negotiation as a refusal? > > The problem isn't that you get a 1.2 ServerHello, it's what happens > after that. The server is going to choke on your 0-RTT data when it > receives that instead of the client's second flight. If it doesn't, > it's probably passing your 0-RTT ciphertext to the application as > plaintext and that's even worse. Why isn't 0-RTT an extension in the Client Hello to deal with this? > > I don't expect people to update their 1.2 implementations to be able > to ignore 0-RTT data. --001a113db6da48d9630535d45026 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 21, 2016 5:44 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>
> On 22 June 2016 at 10:27, Watson Ladd <watsonbladd@gmail.com> wrote:
> > Isn't 0-RTT refusable? Why not treat 1.2 negotiation as a ref= usal?
>
> The problem isn't that you get a 1.2 ServerHello, it's what ha= ppens
> after that.=C2=A0 The server is going to choke on your 0-RTT data when= it
> receives that instead of the client's second flight.=C2=A0 If it d= oesn't,
> it's probably passing your 0-RTT ciphertext to the application as<= br> > plaintext and that's even worse.

Why isn't 0-RTT an extension in the Client Hello to deal= with this?

>
> I don't expect people to update their 1.2 implementations to be ab= le
> to ignore 0-RTT data.

--001a113db6da48d9630535d45026-- From nobody Tue Jun 21 19:31:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3559F12DF35 for ; Tue, 21 Jun 2016 19:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbRE47NQl6Dk for ; Tue, 21 Jun 2016 19:31:34 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 28E0312DF31 for ; Tue, 21 Jun 2016 19:31:34 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id g127so33733134ith.0 for ; Tue, 21 Jun 2016 19:31:34 -0700 (PDT) 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 :cc; bh=fgqEnkSUHEYRpv+7H5Tkb6wgnF+Wler0HUM33OiFHIE=; b=ZZyGCaRnzlEqQFlybRVQXc4BaaTzn1KGQUvD9it0UuvS/JVqZ2DW9oA1gin89zlG+C Z7Y16L81wilStAW4+D16YIWukZwRxj23b2HR3TRm/hAwAf6Q0b3u2XDrHprH1mIiFkWp Xs7K0I8Muc6oJkdvRD1VlGKp7Vgky0w6Mj3gY= 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:cc; bh=fgqEnkSUHEYRpv+7H5Tkb6wgnF+Wler0HUM33OiFHIE=; b=ZzoW+OzzZ3HMIbD907B6vD44rT+lTUbQjE/JU+vcBCxynCZhDxoa9/uBo9cWPd0eei dhREPgqlY1SedRlOIAf1NFNcvhMJroK8rDhI9TiSKA2AzCtdx6tlBVhOG8KiY1rKwH/4 l6N0I34K0XrTS1d0ruJln+Nzgpr/9zO62rbsfbE+ztnnvp3PUW6NASWPZ3x9F4ZpGgsc Hu1408qTnlcmTg2p00WOk7WKkEkRdtxp9BUBaMxW9mdpNHCxgtMF0gWHK7Df7bZdGKj2 /PdY8tSWrMnc3mSx5Y8pVBObuygCUYw5HIuWTbhUFt1H/eymYwP5dBtHop00pAttIbUM c9Ag== X-Gm-Message-State: ALyK8tJ/aJZ0Jm13OU3BSN/X/VbZbef7aGXMKdF0du3U3me/fFr9pD335KyCx7SEsvzHafmG1W7k5t6SW88xMoHI X-Received: by 10.36.11.84 with SMTP id 81mr10956831itd.76.1466562693342; Tue, 21 Jun 2016 19:31:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 22 Jun 2016 02:31:22 +0000 Message-ID: To: Martin Thomson , Bill Frantz Content-Type: multipart/alternative; boundary=001a1140c338610e3b0535d4bc6c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 Jun 2016 02:31:36 -0000 --001a1140c338610e3b0535d4bc6c Content-Type: text/plain; charset=UTF-8 On Tue, Jun 21, 2016 at 8:45 PM Martin Thomson wrote: > On 22 June 2016 at 10:30, Bill Frantz wrote: > > Well, it seems like a browser could try TLS 1.3 without 0-RTT first. > > > > If it connects with 1.3 non-0-RTT, then it could mark the host as not > > supporting 0-RTT for a day or so and after that time retry to see if the > > host has been fixed. > > Yes, that is an option. Harder to manage, but certainly possible and > (overall) preferable to falling back to 1.2. > Right, that (minus the statefulness because I don't care for adding state here) was exactly my intent with the specification text. Don't change the ClientHello version and only retry with the 0-RTT data dropped. It explicitly says "It is NOT RECOMMENDED to retry the connection in response to a more generic error or advertise lower versions of TLS." The version fallback is also inevitable (unless the version negotiation is moved elsewhere), but at least we can separate the two and someday retire the version fallback half. (Also, it's unlikely, but one could also imagine that the retry switches back to hitting a 1.3-capable server. Then changing the ClientHello version will trip fallback detection and the connection will fail again. Whereas retrying with only 0-RTT off is a handshake that will work against 1.2 and 1.3 servers alike.) I don't care much about the exact distribution of MAY/SHOULD/MUST, if that's all we disagree on. If we both agree that browsers will have to fallback, I want the mechanism written down somewhere. Because it's not obvious that this fallback may be triggered without a version downgrade and without a broad trigger, both of which have been problems with the past fallbacks. (The version downgrade has clear security implications and a broad trigger means debugging harder and, worse, it hides bugs. I've seen many cases of server software shipping new code that flat-out doesn't work but fallbacks are so easy to trigger that no one noticed.) Note that, since TLS stacks typically are not in charge of creating sockets, the implementation is the same with or without the fallback. The TLS stack needs to return a very specific error code (<= 1.2 ServerHello in response to 0-RTT ClientHello) and higher-level logic can condition on it as it pleases. David --001a1140c338610e3b0535d4bc6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 21= , 2016 at 8:45 PM Martin Thomson <martin.thomson@gmail.com> wrote:
On 22 June 2016 at 10:30, Bill Frantz <frantz@pwpconsult.co= m> wrote:
> Well, it seems like a browser could try TLS 1.3 without 0-RTT first. >
> If it connects with 1.3 non-0-RTT, then it could mark the host as not<= br> > supporting 0-RTT for a day or so and after that time retry to see if t= he
> host has been fixed.

Yes, that is an option.=C2=A0 Harder to manage, but certainly possible and<= br> (overall) preferable to falling back to 1.2.

Ri= ght, that (minus the statefulness because I don't care for adding state= here) was exactly my intent with the specification text. Don't change = the ClientHello version and only retry with the 0-RTT data dropped. It expl= icitly says "It is NOT RECOMMENDED to retry the connection in response= to a more generic error or advertise lower versions of TLS."

The version fallback is also inevitable (unless the versio= n negotiation is moved elsewhere), but at least we can separate the two and= someday retire the version fallback half.

(Also, = it's unlikely, but one could also imagine that the retry switches back = to hitting a 1.3-capable server. Then changing the ClientHello version will= trip fallback detection and the connection will fail again. Whereas retryi= ng with only 0-RTT off is a handshake that will work against 1.2 and 1.3 se= rvers alike.)

I don't care much about the exac= t distribution of MAY/SHOULD/MUST, if that's all we disagree on. If we = both agree that browsers will have to fallback, I want the mechanism writte= n down somewhere. Because it's not obvious that this fallback may be tr= iggered without a version downgrade and without a broad trigger, both of wh= ich have been problems with the past fallbacks. (The version downgrade has = clear security implications and a broad trigger means debugging harder and,= worse, it hides bugs. I've seen many cases of server software shipping= new code that flat-out doesn't work but fallbacks are so easy to trigg= er that no one noticed.)

Note that, since TLS stac= ks typically are not in charge of creating sockets, the implementation is t= he same with or without the fallback. The TLS stack needs to return a very = specific error code (<=3D 1.2 ServerHello in response to 0-RTT ClientHel= lo) and higher-level logic can condition on it as it pleases.

David
--001a1140c338610e3b0535d4bc6c-- From nobody Tue Jun 21 20:54:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69F312D1AD for ; Tue, 21 Jun 2016 20:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgVfYL9ZqUQn for ; Tue, 21 Jun 2016 20:54:26 -0700 (PDT) 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 748A012D541 for ; Tue, 21 Jun 2016 20:54:26 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id a186so49240184qkf.0 for ; Tue, 21 Jun 2016 20:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KpxLf1A6JnVmmf/7ReecLK0YNpVz441JxDdx1YzRsiw=; b=Tpd0hy2lmt1GwXLjT0TjCdQy1vVB5GcT/sLsadg2qQT8UM8d4Bm9TplhDl8iEop+RD lut2AQVmfBYIusLrjwsg85MzKDKhQS9PpCkAFqIARCFfL1fD4sMpAc7k9IhKxkJfFPfY TIsDfSq4hfFyLFS4FL3GRIvzhd4Ix+xyP+csqcjBQi5rARLH6MURMNb2sFAsxtjJjDAO rZTp2hBcKp3sIneNRsDRgqstmhUhFz92kPBoEndfqAxxoHVPZtGtwGmCENhcaQ+oD+Xz bwDWDB4aZu53HIiWODhYKQlEtCBNWYK/lwzqWn07XcvxFn9VwaJskmnQhlB+09Dbhokh dk7Q== 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; bh=KpxLf1A6JnVmmf/7ReecLK0YNpVz441JxDdx1YzRsiw=; b=HdK39U48NNEb+rSgt2NrNoFruEURakL9I2Cd1+d6a1f1Gl93qBONK8eJ7zKR9TOplR dkJIwWIvVjzVw5xd1e/+iTTbS91Kbc50SlZEnLiUjSEHaSOpy6mN/K12zC+NzLzQawPb Gz1Q9MnIDaT57AfIu/3m3f8dlSfPIEY3R0ecA3gdJrcwKOn6kbxn/glX2vbrZbqMs526 ri+jZ2hl60FTRQ57MKSurQxNsetOxJfsbR0tDAvkSe0IOO1E36SRlVsBzV+I7T/G5PNh +wTDzUw6ihZbDPvL2OC9bcd3FdVEEi41SHQFkxCPypNiF/X9UUuAcGVkBEZKUeCLDw04 czJw== X-Gm-Message-State: ALyK8tJmNTVarDjmVZidf95tZ/Vu2N2oDn5imh5+T09mIxDoLDIA5yUfEmnWyUlFKxQaENY767jrCaQyfJB4fA== X-Received: by 10.55.157.196 with SMTP id g187mr35115733qke.68.1466567665566; Tue, 21 Jun 2016 20:54:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.38 with HTTP; Tue, 21 Jun 2016 20:54:25 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 22 Jun 2016 13:54:25 +1000 Message-ID: To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 Jun 2016 03:54:29 -0000 I've added this option to my PR. I've also weakened the deployment requirement to a SHOULD in light of that. I'll learn to live with the bad taste that leaves :) On 22 June 2016 at 12:31, David Benjamin wrote: > On Tue, Jun 21, 2016 at 8:45 PM Martin Thomson > wrote: >> >> On 22 June 2016 at 10:30, Bill Frantz wrote: >> > Well, it seems like a browser could try TLS 1.3 without 0-RTT first. >> > >> > If it connects with 1.3 non-0-RTT, then it could mark the host as not >> > supporting 0-RTT for a day or so and after that time retry to see if the >> > host has been fixed. >> >> Yes, that is an option. Harder to manage, but certainly possible and >> (overall) preferable to falling back to 1.2. > > > Right, that (minus the statefulness because I don't care for adding state > here) was exactly my intent with the specification text. Don't change the > ClientHello version and only retry with the 0-RTT data dropped. It > explicitly says "It is NOT RECOMMENDED to retry the connection in response > to a more generic error or advertise lower versions of TLS." > > The version fallback is also inevitable (unless the version negotiation is > moved elsewhere), but at least we can separate the two and someday retire > the version fallback half. > > (Also, it's unlikely, but one could also imagine that the retry switches > back to hitting a 1.3-capable server. Then changing the ClientHello version > will trip fallback detection and the connection will fail again. Whereas > retrying with only 0-RTT off is a handshake that will work against 1.2 and > 1.3 servers alike.) > > I don't care much about the exact distribution of MAY/SHOULD/MUST, if that's > all we disagree on. If we both agree that browsers will have to fallback, I > want the mechanism written down somewhere. Because it's not obvious that > this fallback may be triggered without a version downgrade and without a > broad trigger, both of which have been problems with the past fallbacks. > (The version downgrade has clear security implications and a broad trigger > means debugging harder and, worse, it hides bugs. I've seen many cases of > server software shipping new code that flat-out doesn't work but fallbacks > are so easy to trigger that no one noticed.) > > Note that, since TLS stacks typically are not in charge of creating sockets, > the implementation is the same with or without the fallback. The TLS stack > needs to return a very specific error code (<= 1.2 ServerHello in response > to 0-RTT ClientHello) and higher-level logic can condition on it as it > pleases. > > David From nobody Tue Jun 21 20:58:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BFF12D8B9 for ; Tue, 21 Jun 2016 20:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvTQ9-kZpZ6W for ; Tue, 21 Jun 2016 20:58:13 -0700 (PDT) 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 248E612D1AD for ; Tue, 21 Jun 2016 20:58:13 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id a186so49311935qkf.0 for ; Tue, 21 Jun 2016 20:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a6jN6Umt6fN30NrT+uQ/w4jtU5OEA9LJL25ucN4VGM4=; b=QiR6MndT+2kMjd2LrraraVuWGC+PvFlvFzgwTj350mHEihVlEa1MpQ1rBmbaFYRtCh OmltJ4CXpq2tYFkC8GS5vXIeHA7MhLKYd45exqesYVDgtGxiNH+S48O5cmmfWU8/zVeg lWMGUsGap+oB/59I5AcoxG/3sKiXbkOb7P5Pr65mfXB8H+SCKnw+tzR+68l2ZzbsK29Z rzN3UvyRDOEOyWfWSZ8HHs/g5FsKYwT4xQj5+hTWrdRByO+F580Izahd78FzqeeCNJYk mEsyKAK3KTEeeOkMr2CV8Mg6hlMU4x7qv3DqHNh3hdd4KdqPD63ooSUYWbc5HEDXN1y7 J9VQ== 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; bh=a6jN6Umt6fN30NrT+uQ/w4jtU5OEA9LJL25ucN4VGM4=; b=SaybfLh+9cdmbfn9JDg6ydMdZgx9oKLMJnigTkQoShdecM9KqAq2SgSCnN+XLqM2Cn Oh4U+NbWWUa/HQPoxfOlyFzRMfBw2JVqwjUn6i9bTQAKw4K/zjcCeUEz0McCaLe1adOs 4LUrwpuMXy0CN6A2As3Jp9OgF70vED7XREfDe3NBF5C0iNUhxP48BcteJTJ9OwMm9a7K XPlv6V0fp9BqdeWU5aUHv5Killcs5kZSXuI2TL/CQIatYI/swczqEO8FIozJW7wCFLfN ZjGKkWv9et1d0kmj+D8tyY4dNiNhY2eOi0Mm4NFrTIeK1kDVhZ0MiZVTTn2Qonq/ja+i C/Zw== X-Gm-Message-State: ALyK8tKPhTfOx7UceWLe4qPEMyhMppfFkaXmmVrrGbLRa38HH8eoN9Mdmp+76NJTOa90l2n1Dvy7Z6aay8viGg== X-Received: by 10.200.47.156 with SMTP id l28mr34941033qta.20.1466567892374; Tue, 21 Jun 2016 20:58:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.38 with HTTP; Tue, 21 Jun 2016 20:58:11 -0700 (PDT) In-Reply-To: References: <20160621175413.GB2989@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Wed, 22 Jun 2016 13:58:11 +1000 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 Jun 2016 03:58:15 -0000 On 22 June 2016 at 12:01, Watson Ladd wrote: > Why isn't 0-RTT an extension in the Client Hello to deal with this? You can't stream extensions, which unfortunately is required given how most software interacts with their TLS stack. Let's be clear, the actual risk we're talking about is pretty-much confined to screw-ups. The deployment screwup where you left one server speaking TLS 1.2 somewhere before turning 0-RTT on; and TLS MitM, which calling a screw-up might be too positive a statement. Of course, David is right that screw-ups like this are too common for us to do nothing about them. From nobody Wed Jun 22 15:34:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F00512DD4B; Wed, 22 Jun 2016 15:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.328 X-Spam-Level: X-Spam-Status: No, score=-108.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h04vBC4BhU9z; Wed, 22 Jun 2016 15:34:09 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6953112DD4F; Wed, 22 Jun 2016 15:33:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 61465B80C0B; Wed, 22 Jun 2016 15:33:29 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160622223329.61465B80C0B@rfc-editor.org> Date: Wed, 22 Jun 2016 15:33:29 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 7905 on ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 22 Jun 2016 22:34:11 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7905 Title: ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) Author: A. Langley, W. Chang, N. Mavrogiannopoulos, J. Strombergson, S. Josefsson Status: Standards Track Stream: IETF Date: June 2016 Mailbox: agl@google.com, wtc@google.com, nmav@redhat.com, joachim@secworks.se, simon@josefsson.org Pages: 8 Characters: 15575 Updates: RFC 5246, RFC 6347 I-D Tag: draft-ietf-tls-chacha20-poly1305-04.txt URL: https://www.rfc-editor.org/info/rfc7905 DOI: http://dx.doi.org/10.17487/RFC7905 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. This document updates RFCs 5246 and 6347. This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Jun 22 20:37:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8208912DEFB for ; Wed, 22 Jun 2016 20:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IigO_a8QzaH4 for ; Wed, 22 Jun 2016 20:37:16 -0700 (PDT) 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 3333912DEFA for ; Wed, 22 Jun 2016 20:37:16 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id c73so92153392qkg.2 for ; Wed, 22 Jun 2016 20:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=OVI0wVRy8u9SSYUlOrq5Wo0yH2eXqroanC+LxxLLnDs=; b=Gocqwr0OC1vkk9CDCs5sdfm3U4YjzlIiHencfiN/Ys4tV9eHjZuxy8/QxJ/Aiald3b BdG6uBW3UFl+WRpc5r4AszC91yIm+OZMNo2T6OLfXb2VxPtj7eO7n+ysFhjoDo+JgswX Ijwr/Qnfj5X5UciQyCBh8c1OksilXfuSNfhvJpssuXDf5LqcJwnmx6Rd4DH9UoOeYVaJ c/hVZy/iVniRH4jaH0nioz67/mRhSMXYzE4H28syDm2k8NYuhtUI+e2/pexavJ9WYmMl LyqvPcyband+1YDuGkUQuyC6eUUnObqLKQ6PJWb31+veKnKCC2ZAqg7/mmW7wbZaSGHq w8sw== 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; bh=OVI0wVRy8u9SSYUlOrq5Wo0yH2eXqroanC+LxxLLnDs=; b=aZ9F4/cRI2rQyhyg9l+RBwpjcj7Dmu5y1sG47DPIIco4VpzUpihUaMMuYwDa8Dy0tT Q9v5heCEPneSYLr4r676mbTwtuNVbEdfNLwLpvY9ps2PYDIvxObof+3SF2IJ8tUsKYg7 GvhF6wbe2Cwo2SWUOYzazFX2Q1NVdwFNQAOa35v3teZrxBcPd8Z1JUXimpvFzl9alsD9 4EtHviQ6VagL+ozeWRoiiiPMnch5QaUHlPk8QEkt1O99AdBTYbMR5VtKHgYjMzKu4/Gd gR2vSqCF+DeWpLx4pUEcVU8RaWNdBsLzhf0eLTXlEgSAo9xyOTUKqWhN+wgduW+s/QH1 tYwQ== X-Gm-Message-State: ALyK8tL59tjnxnPy4z/2RHyzTdWzxDUkkPJtXXCiBPasYJavcMQhfz01dXkfwj0m82XdtvbRfMZGVknDDsD04g== X-Received: by 10.55.18.194 with SMTP id 63mr8477445qks.199.1466653034973; Wed, 22 Jun 2016 20:37:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.38 with HTTP; Wed, 22 Jun 2016 20:37:14 -0700 (PDT) From: Martin Thomson Date: Thu, 23 Jun 2016 13:37:14 +1000 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Remove EncryptedExtensions from 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Jun 2016 03:37:18 -0000 When implementing 0-RTT, an in particular the ticket_age extension, we discovered that this greatly increases the complexity of the server state machine. The problem is that the server is making decisions about what to send in the ServerHello based on the content of messages that appear after the ClientHello. Worse, this means that the server is making decisions based on material that is not hashed into the session transcript [1]. David Benjamin rather flippantly described a solution to this problem: XOR the ticket age value with something that is either derived from the old session keys or was included in the NewSessionTicket message. I propose we take David's solution. After all, simple is better: https://github.com/tlswg/tls13-spec/pull/503 To be clear, this means we lose the generality provided by having encrypted extensions in the client's first flight. I can't find a reason to be sad about that; the only other possible use for this was encrypted SNI, but I think we can find better ways to solve that particular problem. [1] This lead to ugly patches like what https://github.com/tlswg/tls13-spec/issues/501 suggests. From nobody Wed Jun 22 21:50:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CC812D842 for ; Wed, 22 Jun 2016 21:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQ6zujgXIkoq for ; Wed, 22 Jun 2016 21:50:49 -0700 (PDT) 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 209A112D66C for ; Wed, 22 Jun 2016 21:50:49 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id c73so93519822qkg.2 for ; Wed, 22 Jun 2016 21:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=DvD6BJPjaPUQcv+8H65eSLdazRVVVzBFFYdE1CW5U6c=; b=a7dlRGFriCVEA7MxF9QgAdigfxxPn7uT8e2J76IBBrkU25ii6se2iPW0S29XSHuJna QgNdNcQFFXHbMhZF/B0sLdPvVYJKw+4OiakTbmXALYX30TRMC4rFaRoNbumIj3LiemoU qY2JvPS0Aw8TI9mgnA3ahAnyk+2ffI9d3A58o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=DvD6BJPjaPUQcv+8H65eSLdazRVVVzBFFYdE1CW5U6c=; b=dTT042rNh8zo+mUK/K6MCspmuxo95SjG5xOOIzhp48o2a6NBYADJ1uaWd0Ev3xy5lh 6pdCeyRRM66GtMAXfHDprJPWmjHEACx1qpJC1PZWVzRcktlDi74bmA9eIAYtXU23VqMU mX6R/edCZUBO9e7+Tpl+QXHL18OHymUIZk46SiKMFm8Fri737cvgFjvlWCYRjeqak5PZ ghTnyP0gIjlKJqdY3MFhNgYwd3uuTiLYlKjW8wvDQn2zBgePXj6aIiwGjWkmKkPdfFoA e1/5E7MIWltlcKY3B5YmaG/JFWM8Q2JGn57pSnsjx8zjOGzHpfsEHR3C0gaEvKvnF6MQ v9gQ== X-Gm-Message-State: ALyK8tKDKkBt1T62ZdU4/b+nbNW60uldqbtC2m+hdKzryf4CeWjw19mtLZUO8xWl7TY8bQ== X-Received: by 10.200.47.107 with SMTP id k40mr39293818qta.86.1466657448146; Wed, 22 Jun 2016 21:50:48 -0700 (PDT) Received: from [172.16.0.112] ([96.231.230.69]) by smtp.gmail.com with ESMTPSA id b137sm1563672qkg.4.2016.06.22.21.50.47 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 22 Jun 2016 21:50:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <20160622223329.61465B80C0B@rfc-editor.org> Date: Thu, 23 Jun 2016 00:50:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <68FF7264-480C-4746-B4BE-D5123A753E51@sn3rd.com> References: <20160622223329.61465B80C0B@rfc-editor.org> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] RFC 7905 on ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Jun 2016 04:50:51 -0000 Congrats to all involved! spt > On Jun 22, 2016, at 18:33, rfc-editor@rfc-editor.org wrote: >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7905 >=20 > Title: ChaCha20-Poly1305 Cipher Suites for=20 > Transport Layer Security (TLS)=20 > Author: A. Langley,=20 > W. Chang, > N. Mavrogiannopoulos, > J. Strombergson, > S. Josefsson > Status: Standards Track > Stream: IETF > Date: June 2016 > Mailbox: agl@google.com, > wtc@google.com, > nmav@redhat.com, > joachim@secworks.se,=20 > simon@josefsson.org > Pages: 8 > Characters: 15575 > Updates: RFC 5246, RFC 6347 >=20 > I-D Tag: draft-ietf-tls-chacha20-poly1305-04.txt >=20 > URL: https://www.rfc-editor.org/info/rfc7905 >=20 > DOI: http://dx.doi.org/10.17487/RFC7905 >=20 > 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. >=20 > This document updates RFCs 5246 and 6347. >=20 > This document is a product of the Transport Layer Security Working = Group of the IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and = suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for = the=20 > standardization state and status of this protocol. Distribution of = this=20 > memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 From nobody Thu Jun 23 03:35:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF63E12E24F for ; Thu, 23 Jun 2016 03:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qQK7UFP6TuF for ; Thu, 23 Jun 2016 03:35:50 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id B465012E22F for ; Thu, 23 Jun 2016 03:35:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 8926723DE; Thu, 23 Jun 2016 13:35:47 +0300 (EEST) 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 E-qTIXfbOURx; Thu, 23 Jun 2016 13:35:47 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 2B0F02317; Thu, 23 Jun 2016 13:35:47 +0300 (EEST) Date: Thu, 23 Jun 2016 13:35:46 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20160623103546.GA5287@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove EncryptedExtensions from 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Jun 2016 10:35:53 -0000 On Thu, Jun 23, 2016 at 01:37:14PM +1000, Martin Thomson wrote: > When implementing 0-RTT, an in particular the ticket_age extension, we > discovered that this greatly increases the complexity of the server > state machine. > > David Benjamin rather flippantly described a solution to this problem: > XOR the ticket age value with something that is either derived from > the old session keys or was included in the NewSessionTicket message. > > I propose we take David's solution. After all, simple is better: > > https://github.com/tlswg/tls13-spec/pull/503 I don't see a warning that reusing a ticket with that scheme causes the "masking" to break (the classic "multiple time pad" broken scheme). -Ilari From nobody Thu Jun 23 07:26:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D5B12D0DA for ; Thu, 23 Jun 2016 07:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ANs8VklOhP1 for ; Thu, 23 Jun 2016 07:26:40 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 0D03B12B029 for ; Thu, 23 Jun 2016 07:26:40 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id d185so108421087vkg.0 for ; Thu, 23 Jun 2016 07:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8Y1ATggzQNVtJosX6gDFpyh1FLscSpn000lzKHaoEWM=; b=LegaSROoykrFZNtfz63nG/DmckHEuZU1poMBo+227RlyYV116TGjyjZjplEInKEhFa CP5Iwy5hMwqr7UnLQopYSGnH8uSFNV+zmpMvIojmOj/7hLnS3hVrWF0uo4gQaHq/e4Z/ NsbSDjmqxMPCEEokdZpZDM9W6M+XZKYXXPjEmf3uQHyXYGr9vn97A3zbyh9Y8Cyn0t5s NqUwlaD5SUa3zkaBm1jocvA7nUT0jAV71FR3hwUTTN2Lb9naKkNseRghOPDeJBtziLXG xM3TCIYBCYeX985hWzEtyETGhzgAKEJGF2o3EvVbDFoeoCHNEtszt0AgDkPn9BHADeOg uAsQ== 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; bh=8Y1ATggzQNVtJosX6gDFpyh1FLscSpn000lzKHaoEWM=; b=QzEueZxOKzJz3UJbnSI164beyiZxS56YQNnq+rMtKG7De8PkpS/5U29D1YBDn72zCj gKQffxbiVIzA+6QZVKKjfNH42hua8DELEcf9pYpwbx+eZVfbnr5uBQyjiL3tc5Tm5oLG LTaxRBlyZf3iWl+7+UxUPOZF9SE16966m/w4CCtCYeil9+7ath08x2SIe7Zu5gl6OKZB cI3E4yWuFdk5+5hwRCHb9WsBEwllzQrfBOFDe/7tJZtkKR6U7/NyFbQtfjDqfHAiQ7nt ucwU4qpTOPyVIcZEr6V1FEj0h9R0+60B7M+dY4MKOZI8o5trM9E0tyWgv8hy6rs72Wvs 5L+Q== X-Gm-Message-State: ALyK8tKX14gWTy2hSuUVz9+CAG9rA4JqUea1vtpJZIbhSjczTwZreTSMFEoaSt7GjF2JDA/od2Jfx0f/y6FEcQ== X-Received: by 10.31.129.203 with SMTP id c194mr6434410vkd.26.1466691999092; Thu, 23 Jun 2016 07:26:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.35.78 with HTTP; Thu, 23 Jun 2016 07:26:37 -0700 (PDT) In-Reply-To: References: <20160621175413.GB2989@LK-Perkele-V2.elisa-laajakaista.fi> From: Watson Ladd Date: Thu, 23 Jun 2016 07:26:37 -0700 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Jun 2016 14:26:42 -0000 On Tue, Jun 21, 2016 at 8:58 PM, Martin Thomson wrote: > On 22 June 2016 at 12:01, Watson Ladd wrote: >> Why isn't 0-RTT an extension in the Client Hello to deal with this? > > You can't stream extensions, which unfortunately is required given how > most software interacts with their TLS stack. A few months ago we had a lengthy discussion on the list and at TRON about how risky 0-RTT is. This culminated in the idea that 0RTT data should be provided through a distinct channel to the application, along with feedback about whether it was not accepted. If we're willing to change the interaction pattern to support that, we can accommodate using 0RTT as an extension by gathering it all and sending when the handshake happens. But it sounds like you are discussing a design where the handshake fakes completion if 0-RTT is on, and at some point later "well, i didn't actually send the data you wanted to". Or am I missing something about the API design that is motivating this streaming approach? > > Let's be clear, the actual risk we're talking about is pretty-much > confined to screw-ups. The deployment screwup where you left one > server speaking TLS 1.2 somewhere before turning 0-RTT on; and TLS > MitM, which calling a screw-up might be too positive a statement. Or you turned on 0-RTT and then got a security advisory resulting in rolling back to TLS 1.2. > > Of course, David is right that screw-ups like this are too common for > us to do nothing about them. -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu Jun 23 07:47:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D20128E18 for ; Thu, 23 Jun 2016 07:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buLjWIbmKDcs for ; Thu, 23 Jun 2016 07:47:45 -0700 (PDT) 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 5957B12B00E for ; Thu, 23 Jun 2016 07:39:34 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id s63so69387749ioi.3 for ; Thu, 23 Jun 2016 07:39:34 -0700 (PDT) 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 :cc; bh=MfBltjJqCnRtGl32I2pr+/SfEz5brdz2GWow4K/2z5k=; b=JC5w46W/lDq98MhhOebYWj4MeKVmvajB/sH1lIo5/xZ3uQa3Bk9dZI9WsDUTC3p6Ld C02R/xV4kPiOb7nOehKubljhc05fshCWJgRUtNfR2iRf2BW89RUZKeOdidx+380MLcHz WCHJ2eMdhoPKEMkzM3xNKEB/1QphcA9P8DnMw= 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:cc; bh=MfBltjJqCnRtGl32I2pr+/SfEz5brdz2GWow4K/2z5k=; b=HDDmpZM7b7B1USMANj/elH5Imaba4kEYZnbg3nqx8/NnDnRiJN/v7e1Ir72b9ykfbJ +5C2DmV4MsoLPWqovd/QUXcntJjJFeLMgUahIasgf+JiyenhfT582ffnBRvL5O9ypSfR q2KaX1+BdYQnviaQSqdWUpQg87WrOOtt/9aOeKFmgh1u440oNlk2Gp3MaN8tFZP5dxr3 Udm6R8KRnxUxAYZ6SaRdvoK1ZE7JCtKxwOLX2BavfTdl2Cdg6ipPU8xYrFjJdFbNsXhp qWQX1xVcdrhlohufVjia4UzMIr8YL9gp3D+9qIdOMnBP477hOh15PAJFNNfeYt+/7I6E NQKg== X-Gm-Message-State: ALyK8tKaJO/67yYnLs7r87ym0EF5CEFaceF6j0Z8p1oDHvRn/UYM4ZaofRVq9q+4rY91qe70F4NwJwvonfyMHKZT X-Received: by 10.107.29.80 with SMTP id d77mr1268136iod.97.1466692773365; Thu, 23 Jun 2016 07:39:33 -0700 (PDT) MIME-Version: 1.0 References: <20160623103546.GA5287@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160623103546.GA5287@LK-Perkele-V2.elisa-laajakaista.fi> From: David Benjamin Date: Thu, 23 Jun 2016 14:39:22 +0000 Message-ID: To: Ilari Liusvaara , Martin Thomson Content-Type: multipart/alternative; boundary=001a11408bf2c0a9b30535f305cb Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove EncryptedExtensions from 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Jun 2016 14:47:48 -0000 --001a11408bf2c0a9b30535f305cb Content-Type: text/plain; charset=UTF-8 On Thu, Jun 23, 2016 at 6:35 AM Ilari Liusvaara wrote: > On Thu, Jun 23, 2016 at 01:37:14PM +1000, Martin Thomson wrote: > > When implementing 0-RTT, an in particular the ticket_age extension, we > > discovered that this greatly increases the complexity of the server > > state machine. > > > > David Benjamin rather flippantly described a solution to this problem: > > XOR the ticket age value with something that is either derived from > > the old session keys or was included in the NewSessionTicket message. > > > > I propose we take David's solution. After all, simple is better: > > > > https://github.com/tlswg/tls13-spec/pull/503 > > I don't see a warning that reusing a ticket with that scheme causes > the "masking" to break (the classic "multiple time pad" broken scheme). > Probably worth expanding on in the text, but the assumption here is that EncryptedExtensions' only purpose in life was to defeat correlation. That is, if we didn't care about that, we'd put it in the clear like other ClientHello fields. (Which means integrity is provided by handshake transcript, as with other ClientHello fields.) To that end, if you were reusing a ticket, you've already leaked a more fun correlator (the ticket) and must not have cared about leaking the ticket_age either. If something more heavyweight is wanted, probably better to derive some extra key off the session key material + stuff (ought to include client_random if worried about ticket reuse) and toss it into the cipher's AEAD or something. It didn't seem we needed any of it, so I "flippantly" proposed the dumbest possible thing that might work. :-) David --001a11408bf2c0a9b30535f305cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 23= , 2016 at 6:35 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Thu, Jun 23, 2016 at 01:37:14PM +1000, Martin Thomson wrot= e:
> When implementing 0-RTT, an in particular the ticket_age extension, we=
> discovered that this greatly increases the complexity of the server > state machine.
>
> David Benjamin rather flippantly described a solution to this problem:=
> XOR the ticket age value with something that is either derived from > the old session keys or was included in the NewSessionTicket message.<= br> >
> I propose we take David's solution.=C2=A0 After all, simple is bet= ter:
>
>=C2=A0 =C2=A0https://github.com/tlswg/tls13-spec/pul= l/503

I don't see a warning that reusing a ticket with that scheme causes
the "masking" to break (the classic "multiple time pad"= broken scheme).

Probably worth expandi= ng on in the text, but the assumption here is that EncryptedExtensions'= only purpose in life was to defeat correlation. That is, if we didn't = care about that, we'd put it in the clear like other ClientHello fields= . (Which means integrity is provided by handshake transcript, as with other= ClientHello fields.)

To that end, if you were reu= sing a ticket, you've already leaked a more fun correlator (the ticket)= and must not have cared about leaking the ticket_age either.

If something more heavyweight is wanted, probably better to= derive some extra key off the session key material + stuff (ought to inclu= de client_random if worried about ticket reuse)=C2=A0and toss it into the c= ipher's AEAD or something. It didn't seem we needed any of it, so I= "flippantly" proposed the dumbest possible thing that might work= . :-)

David
--001a11408bf2c0a9b30535f305cb-- From nobody Thu Jun 23 08:06:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8051612D193 for ; Thu, 23 Jun 2016 08:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyLei5otpCHg for ; Thu, 23 Jun 2016 08:06:05 -0700 (PDT) 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 3782D12D18E for ; Thu, 23 Jun 2016 08:06:05 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id t74so74100673ioi.0 for ; Thu, 23 Jun 2016 08:06:05 -0700 (PDT) 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 :cc; bh=HLjzO68frZJ8SZUAPr7HceSsBzt36sXRSr+G4JtsQEc=; b=IHHeTWrEzesLaFjuMpE6un/fBlCkAX1hHcA+sRr6UAZcYcmCghmiYmKNnA7qF1c3Ql Kzs9C7K6DvAZLryefDRrBQeYyGfEPbu3DkJwlfcvnTf4hAwoF4HYRypx2lxgp7kv6z9N vhbMEtfjviyqxojfVmZtWxJ78IWgBsmsOK80Q= 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:cc; bh=HLjzO68frZJ8SZUAPr7HceSsBzt36sXRSr+G4JtsQEc=; b=cY6zKij0arQpzPhev0mV9C6qp5OOanJLCMeLNgDYB5Zc1FEKWUqqDaDEc0gJRXL+mW ex6MY7eHr43/dSTsW4dWHy08mIT+q3JoCAFS15GpoTlNd0zjgjVnsi//rAyDPOErKENQ T34OdPk8NEeiFMO2gEOffbOkgNO7HZ8wA/Q0pKTbBOmK9+LtxU9h3JI3lUAcAjVnbsgi SFIdGhuCDmLJSbHKybfbRBKUHXudcO/zGTNg52nmtGySK6A21FloKgpt0ifa0MF4JNVu H0zBSmjcXOxPk1+igZdn5xXKWdP5DyF1iuSOfyWR5cwrK5Zr64Nlmvl2AtIeP2pyfzb0 S+Ww== X-Gm-Message-State: ALyK8tLK5kYjUaArbzvmRccwnkkrhyEk8NG+QFgH1oxEa0wRJo6K61b2V9LHXZfnGG56VUoofm1kokXfInn7oUER X-Received: by 10.107.29.80 with SMTP id d77mr1412138iod.97.1466694364355; Thu, 23 Jun 2016 08:06:04 -0700 (PDT) MIME-Version: 1.0 References: <20160623103546.GA5287@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: From: David Benjamin Date: Thu, 23 Jun 2016 15:05:54 +0000 Message-ID: To: Ilari Liusvaara , Martin Thomson Content-Type: multipart/alternative; boundary=001a11408bf2952fa50535f3645d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove EncryptedExtensions from 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Jun 2016 15:06:07 -0000 --001a11408bf2952fa50535f3645d Content-Type: text/plain; charset=UTF-8 On Thu, Jun 23, 2016 at 6:35 AM David Benjamin wrote: > On Thu, Jun 23, 2016 at 6:35 AM Ilari Liusvaara > wrote: > >> On Thu, Jun 23, 2016 at 01:37:14PM +1000, Martin Thomson wrote: >> > When implementing 0-RTT, an in particular the ticket_age extension, we >> > discovered that this greatly increases the complexity of the server >> > state machine. >> > >> > David Benjamin rather flippantly described a solution to this problem: >> > XOR the ticket age value with something that is either derived from >> > the old session keys or was included in the NewSessionTicket message. >> > >> > I propose we take David's solution. After all, simple is better: >> > >> > https://github.com/tlswg/tls13-spec/pull/503 >> >> I don't see a warning that reusing a ticket with that scheme causes >> the "masking" to break (the classic "multiple time pad" broken scheme). >> > > Probably worth expanding on in the text, but the assumption here is that > EncryptedExtensions' only purpose in life was to defeat correlation. That > is, if we didn't care about that, we'd put it in the clear like other > ClientHello fields. (Which means integrity is provided by handshake > transcript, as with other ClientHello fields.) > > To that end, if you were reusing a ticket, you've already leaked a more > fun correlator (the ticket) and must not have cared about leaking the > ticket_age either. > I suppose there is a slight difference from ticket reuse in that ticket reuse correlates the resumption connections together but not the connection which minted the ticket. The ticket age helps you correlate that initial connection too. I don't think this matters. Just don't reuse tickets. But, if we cared, per the "dumbest possible thing that might work" school of thought, we can replace XOR with addition modulo 2^32. Now ticket reuse leaks the delta between two ClientHellos, which, precision aside, was already public information from the receive time (with ticket as correlator). The timestamp of the ticket-minting connection is as secret as before. > If something more heavyweight is wanted, probably better to derive some > extra key off the session key material + stuff (ought to include > client_random if worried about ticket reuse) and toss it into the cipher's > AEAD or something. It didn't seem we needed any of it, so I "flippantly" > proposed the dumbest possible thing that might work. :-) > > David > --001a11408bf2952fa50535f3645d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 23= , 2016 at 6:35 AM David Benjamin <davidben@chromium.org> wrote:
On Thu, J= un 23, 2016 at 6:35 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Thu, Jun 23, 2016 at 01:37:14PM +1000= , Martin Thomson wrote:
> When implementing 0-RTT, an in particular the ticket_age extension, we=
> discovered that this greatly increases the complexity of the server > state machine.
>
> David Benjamin rather flippantly described a solution to this problem:=
> XOR the ticket age value with something that is either derived from > the old session keys or was included in the NewSessionTicket message.<= br> >
> I propose we take David's solution.=C2=A0 After all, simple is bet= ter:
>
>=C2=A0 =C2=A0https://github.com/tlswg/tls13-spec/pul= l/503

I don't see a warning that reusing a ticket with that scheme causes
the "masking" to break (the classic "multiple time pad"= broken scheme).

Probably worth expanding on in the text, = but the assumption here is that EncryptedExtensions' only purpose in li= fe was to defeat correlation. That is, if we didn't care about that, we= 'd put it in the clear like other ClientHello fields. (Which means inte= grity is provided by handshake transcript, as with other ClientHello fields= .)

To that end, if you were reusing a ticket, you&= #39;ve already leaked a more fun correlator (the ticket) and must not have = cared about leaking the ticket_age either.

I suppose there is a slight difference from ticket reuse = in that ticket reuse correlates the resumption connections together but not= the connection which minted the ticket. The ticket age helps you correlate= that initial connection too.

I don't think th= is matters. Just don't reuse tickets. But, if we cared, per the "d= umbest possible thing that might work" school of thought, we can repla= ce XOR with addition modulo 2^32. Now ticket reuse leaks the delta between = two ClientHellos, which, precision aside, was already public information fr= om the receive time (with ticket as correlator). The timestamp of the ticke= t-minting connection is as secret as before.
=C2=A0
If = something more heavyweight is wanted, probably better to derive some extra = key off the session key material + stuff (ought to include client_random if= worried about ticket reuse)=C2=A0and toss it into the cipher's AEAD or= something. It didn't seem we needed any of it, so I "flippantly&q= uot; proposed the dumbest possible thing that might work. :-)

David
--001a11408bf2952fa50535f3645d-- From nobody Thu Jun 23 08:53:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBB112B028 for ; Thu, 23 Jun 2016 08:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vT-lQErNMOwv for ; Thu, 23 Jun 2016 08:53:42 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3B63012B034 for ; Thu, 23 Jun 2016 08:53:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 9E3607DD5; Thu, 23 Jun 2016 18:53:40 +0300 (EEST) 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 RjAsuqtDZM-A; Thu, 23 Jun 2016 18:53:40 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 515C92317; Thu, 23 Jun 2016 18:53:40 +0300 (EEST) Date: Thu, 23 Jun 2016 18:53:39 +0300 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20160623155339.GA5659@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160621175413.GB2989@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.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Jun 2016 15:53:45 -0000 On Thu, Jun 23, 2016 at 07:26:37AM -0700, Watson Ladd wrote: > On Tue, Jun 21, 2016 at 8:58 PM, Martin Thomson > wrote: > > On 22 June 2016 at 12:01, Watson Ladd wrote: > >> Why isn't 0-RTT an extension in the Client Hello to deal with this? > > > > You can't stream extensions, which unfortunately is required given how > > most software interacts with their TLS stack. > > A few months ago we had a lengthy discussion on the list and at TRON > about how risky 0-RTT is. This culminated in the idea that 0RTT data > should be provided through a distinct channel to the application, > along with feedback about whether it was not accepted. If we're > willing to change the interaction pattern to support that, we can > accommodate using 0RTT as an extension by gathering it all and sending > when the handshake happens. But it sounds like you are discussing a > design where the handshake fakes completion if 0-RTT is on, and at > some point later "well, i didn't actually send the data you wanted > to". Or am I missing something about the API design that is motivating > this streaming approach? Sticking 0-RTT data into ClientHello also has the following problems: - One needs to mangle ClientHello (strip an extension on receiver side) to obtain hash suitable for key derivation for 0-RTT. To do it any other way either doesn't work, or are cryptographically quite risky. - It bloats ClientHello, something you rather not bloat, especially with DTLS. And one still has to keep the data separate. For one, one can't guarantee non-replay (no, the ticket age won't cut it, for both fundamental and practical reasons). The streaming appoach on client end could take forms of either pre-collecting the data, or callback after ClientHello (and the assorted hashes being known, altough the latter is somewhat more dangerous...) And BTW, that 0-RTT Finished message is quite annoying... -Ilari From nobody Thu Jun 23 13:59:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCD412D625 for ; Thu, 23 Jun 2016 13:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygAOq3bdnnZB for ; Thu, 23 Jun 2016 13:59:30 -0700 (PDT) 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 5175B12D614 for ; Thu, 23 Jun 2016 13:59:30 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id p10so122933987qke.3 for ; Thu, 23 Jun 2016 13:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lH23cJmsH/NuNCobhvTQFVnRKm0a+8K+Fc9M2Ly+hPI=; b=SSgYTCYoWGK2k0F08mYj8Y2srpUIpR6ARUQNUEwa5g2jwncK4pQFME+76KnUWNuqwY 30OfcPY6KTe2aFJrBfBSw2dZiTCQgjPTfGXA/JJn9b0M8L+/2Ee2liX4Y3MLhv/nObg+ uv3AGxbrqcZRjBMnueFWbRql/FXDgtGk08uiJKkX3NRYy0W8lV+8cotA2cI+Mdd9+kps +TSPQ2MvfWSfRiD5/gdrEYuma7QMq2ttYd6sYnuo60ViHB0zMYumHMHxeo8mx5kbmaA/ HUVhuVuIlnS3busgxEwAjXOL5YV6iFUsSd4AEZ73cTab945LQk32aNf1r2mm1ZiRn88a tMPQ== 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; bh=lH23cJmsH/NuNCobhvTQFVnRKm0a+8K+Fc9M2Ly+hPI=; b=ZjSqGa/0mGPrKecQYS5HRPVMaPnhyFAkWAU7z5a1RMrruoI2969tixsssk0jhfDlzG RXyk03eAz33Mon7GfTRtVYzhyOyYCn8Sg8qnjzEgXJIqt7MOwgFHPmZv+EZ1gQBEQ+Pb AHk8RqPeRa0sJ58oI22f/t03yASmxlWTHs2zMmiN/WMPgoDYc/ruAUbcLflrpl9zHG2K aK4TAiWR14mS4NRzEQ6aEnBLYhok+6Gs64zBuCPxMsufIeCFohddnN19pgP2C1+oEHyO blbawUVVHUGNxM0KgTR1ZfuuUGrg3IytSS0k0D2QZfU3CMADSmN388Fhei5XBqzuDA96 aPyg== X-Gm-Message-State: ALyK8tIol3MhvrLgPv1U0NQCZnSdQ9BPRrWbBBqGaHJurrvuuvMUG70YlZfzIsUlai6OO4eAlQJO2AFifVIJfQ== X-Received: by 10.237.57.41 with SMTP id l38mr675724qte.74.1466715569414; Thu, 23 Jun 2016 13:59:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.38 with HTTP; Thu, 23 Jun 2016 13:59:28 -0700 (PDT) In-Reply-To: References: <20160623103546.GA5287@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Fri, 24 Jun 2016 06:59:28 +1000 Message-ID: To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove EncryptedExtensions from 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Jun 2016 20:59:32 -0000 On 24 June 2016 at 01:05, David Benjamin wrote: > I don't think this matters. Just don't reuse tickets. But, if we cared, per > the "dumbest possible thing that might work" school of thought, we can > replace XOR with addition modulo 2^32. Now ticket reuse leaks the delta > between two ClientHellos, which, precision aside, was already public > information from the receive time (with ticket as correlator). The timestamp > of the ticket-minting connection is as secret as before. That sounds like fine reasoning to me. XOR or addition are both easy enough to specify. From nobody Thu Jun 23 14:03:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6594112D1A2 for ; Thu, 23 Jun 2016 14:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq4LoCfbelQX for ; Thu, 23 Jun 2016 14:03:39 -0700 (PDT) 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 A4E4A12D614 for ; Thu, 23 Jun 2016 14:03:39 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id t127so122925473qkf.1 for ; Thu, 23 Jun 2016 14:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oIL8NV/xOIfcwnzFS+szytBQN9mvWWdq47XTdhUjUck=; b=i0pH6FdgYdPkqMuCrCk+kR3Gy/CobNXZmwS0HEtThlLkjVJEEATa7/8MkaU2VY2wza N1XvhOPJAzRBPSKHZ0pANxV9YeJLW1aKSGCm8g7lRylXp7ThGr0Ymp9rrMv+8huiXalo VSNj6c1IFYbKwZsz2s5eJYD52I2JYVXh1NbY0FODv8/PPHkrrwM+j1LazM+A4ronsWXX 4QO83VZA5x+z11o5deu+T/UYgVL+jXf9wJlCy336eD8qc+vJ7MCCMI0BJHtk0erINFl5 rC8CN76nGgQXQc81wpqEdN4gWzDgvtuKxE38PvH21hZ/DaYeAldu5puoosyUB91Wloh/ CllQ== 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; bh=oIL8NV/xOIfcwnzFS+szytBQN9mvWWdq47XTdhUjUck=; b=DU1UcuHhzmaZRcp/XCsR0AZciC2c2RbF15MZQzuFin8m2v1uY0OTtRwEQj9YqfjMBm rLvL3Va38koLClPtSEKXpW90sl97nM9Y3kjDbpzZ81Q0CEEhmpMShHrthdbYolaN+0je 2cUcJIR+77ehvDSMWbSfbx9qnW8RVfEqC55zVMhHdO9/y1nHHXmj45rdB4D2Pf6Qnyph woCqgsmoyqHMtIcFcgjn2qIJzPXvow5SQIGsAGRo5pbVACl+QRY/g6uMseaykPevy117 YbddveAxJbfCGaA5m3Rmik7xlFEBnwyv+b1hbCM9WMezUDeJZvRB/c2ZnVvPRv+M+flp DJ0A== X-Gm-Message-State: ALyK8tK6O6OhKSgqPM6rO9Ce+v2k5xy2+FlTr6DS+/66axlqPG7DnU1Fu4vTJCMjnuhW/2o6T4fGh4K7DYCpPQ== X-Received: by 10.55.118.196 with SMTP id r187mr711343qkc.32.1466715818870; Thu, 23 Jun 2016 14:03:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.38 with HTTP; Thu, 23 Jun 2016 14:03:38 -0700 (PDT) In-Reply-To: References: <20160621175413.GB2989@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Fri, 24 Jun 2016 07:03:38 +1000 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Jun 2016 21:03:41 -0000 On 24 June 2016 at 00:26, Watson Ladd wrote: > If we're > willing to change the interaction pattern to support that, we can > accommodate using 0RTT as an extension by gathering it all and sending > when the handshake happens. That's a very different constraint on the usage. In one, you have to identify data as being "for 0-RTT" very explicitly. In the other, you have to have all the data available when you send a ClientHello. The latter is rarely the case. > But it sounds like you are discussing a > design where the handshake fakes completion if 0-RTT is on, and at > some point later "well, i didn't actually send the data you wanted > to". Or am I missing something about the API design that is motivating > this streaming approach? I don't think that's what I'm suggesting. I don't intend to change the signals in the current draft, namely that the handshake indicates the presence (ClientHello) and acceptance (ServerHello) of 0-RTT. From nobody Fri Jun 24 09:05:33 2016 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 275D112DCE6; Fri, 24 Jun 2016 09:00:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160053.10933.60957.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:53 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] tls - Requested session has been scheduled for IETF 96 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the mailing list 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, 24 Jun 2016 16:00:56 -0000 Dear Joseph Salowey, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tls Session 1 (2:30:00) Tuesday, Morning Session I 1000-1230 Room Name: Charlottenburg II/III size: 175 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Joseph Salowey Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: curdle uta acme cose cfrg dane httpbis httpauth rtcweb saag stir tcpinc tokbind perc Second Priority: sacm oauth Special Requests: Please also avoid the quic BOF. --------------------------------------------------------- From nobody Sat Jun 25 06:11:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3D612D598 for ; Thu, 23 Jun 2016 01:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0UOD_-2IFi8 for ; Thu, 23 Jun 2016 01:18:28 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 D0F6912D52D for ; Thu, 23 Jun 2016 01:18:28 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id g127so64231617ith.0 for ; Thu, 23 Jun 2016 01:18:28 -0700 (PDT) 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; bh=Yxah6TCA3tkDH+9nyZmB4ajUwZ3yB5qwft0CqcF/mjE=; b=Yo7pCjIlcAZX1g3sPArRumXP+nWlkbvJV2+0bZdXy1cPUFhNkojnx6TSKN2WPnD7E4 S6H+snz80UC2YEFy+ZwMDakfRrA2h53GPNPV9ds3DWFhTtBU8lCcNlkDVUEcD2F+hQVv fhu6N8nrd7eG2lv09ghOwRmgvgvZL1pKVNU0/+lgRRk9PXdBdLQhZ0w73t2wrrhOTtHc G0DIJoepUujAjErLm9Sw4kgFKwyduWOaennM8cBNoKpuPEPLgY4fY78ditfJZf/5pVto ekDn+sHk570Y7kxaZJfWoq812M4BGMUHxnS+rhbhXlmgyi2y7Bf5oYaPrXHmrOWYUwau CoBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=Yxah6TCA3tkDH+9nyZmB4ajUwZ3yB5qwft0CqcF/mjE=; b=Oehof7kY+vYXW+l5Fn0hI80yxRfMF8cX0wfndkdOxIsmPiYyeioV/o4cT2OhzWijak 30MTgoiOqrfERYumzBExLFNKRfh6z5J8SjerCgGxjRfJlieNGl+dbXBNh6fC1y5kyVj3 cVbSjstfJ9VzEQ+O4dLfkz0ZSwRBKlsavbBUCIb7F3MCl72H1kilqmL9ZvCq6e2qafqg wnqsfoq0PEGo1mdbglRR+NRfwJB4BAVWO36vQUkIWTWzyHsZX1H9h6+3R/bpbFygei5I 3NRPzEcaKbtfVffsUo2QA2n3qK8HTumrrqDcYpzV6LZR/1oXGkO4yFK9U8RjAU579pwk xIXQ== X-Gm-Message-State: ALyK8tIK+BA6zB7VOfvwNpDv9rfePkSoBSYnMD5s2UqUpaOKozQxMvcsRAnHvUdIZoKfeuwWIWXHojGTqeujmQ== MIME-Version: 1.0 X-Received: by 10.36.44.200 with SMTP id i191mr18157751iti.99.1466669908072; Thu, 23 Jun 2016 01:18:28 -0700 (PDT) Received: by 10.107.128.65 with HTTP; Thu, 23 Jun 2016 01:18:27 -0700 (PDT) Received: by 10.107.128.65 with HTTP; Thu, 23 Jun 2016 01:18:27 -0700 (PDT) In-Reply-To: References: <20160621175413.GB2989@LK-Perkele-V2.elisa-laajakaista.fi> Date: Thu, 23 Jun 2016 10:18:27 +0200 Message-ID: From: Erik Nygren To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113f9f6cdfa35c0535edb231 Archived-At: X-Mailman-Approved-At: Sat, 25 Jun 2016 06:11:32 -0700 Cc: tls@ietf.org Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: erik@nygren.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, 23 Jun 2016 08:18:31 -0000 --001a113f9f6cdfa35c0535edb231 Content-Type: text/plain; charset=UTF-8 There are also very common cases of using multiple CDNs or server farms with different capabilities but with the same host name, or of switching a live site between platforms. As others have mentioned, the behaviors need to be well defined and result in extra rtt rather than hard failure to allow 0rtt to be safely deployable. - Erik On Jun 22, 2016 5:58 AM, "Martin Thomson" wrote: On 22 June 2016 at 12:01, Watson Ladd wrote: > Why isn't 0-RTT an extension in the Client Hello to deal with this? You can't stream extensions, which unfortunately is required given how most software interacts with their TLS stack. Let's be clear, the actual risk we're talking about is pretty-much confined to screw-ups. The deployment screwup where you left one server speaking TLS 1.2 somewhere before turning 0-RTT on; and TLS MitM, which calling a screw-up might be too positive a statement. Of course, David is right that screw-ups like this are too common for us to do nothing about them. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --001a113f9f6cdfa35c0535edb231 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

There are also very common cases of using multiple CDNs or s= erver farms with different capabilities but with the same host name, or of = switching a live site between platforms. As others have mentioned, the beha= viors need to be well defined and result in extra rtt rather than hard fail= ure to allow 0rtt to be safely deployable.

- Erik

On Jun 22, 2016 5:58 AM, "Martin Thomson&qu= ot; <martin.thomson@gmail.co= m> wrote:
On 22 June 2016 at 12:01, Watson Ladd <watsonbladd@gmail.com> wrote:
> Why isn't 0-RTT an extension in the Client Hello to deal with this= ?

You can't stream extensions, which unfortunately is required give= n how
most software interacts with their TLS stack.

Let's be clear, the actual risk we're talking about is pretty-much<= br> confined to screw-ups.=C2=A0 The deployment screwup where you left one
server speaking TLS 1.2 somewhere before turning 0-RTT on; and TLS
MitM, which calling a screw-up might be too positive a statement.

Of course, David is right that screw-ups like this are too common for
us to do nothing about them.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a113f9f6cdfa35c0535edb231-- From nobody Sat Jun 25 22:34:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C7912B049 for ; Sat, 25 Jun 2016 22:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q58BYolBGkFm for ; Sat, 25 Jun 2016 22:34:07 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 8A8C912B041 for ; Sat, 25 Jun 2016 22:34:07 -0700 (PDT) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u5Q5WI5Z003840; Sat, 25 Jun 2016 22:34:06 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=nBKJTJBI4iK9bss54shnkeVw2gWrN+/+e8Xo/Iz1AUQ=; b=DaQA5sIatv8ZtqnddHoOcugZ9ZyIrjahC4ej1AxPs2qdFB6ShCSg6gTqFjttSBWay76G 527leecIQsQPxso1mqhtnoa8oyurauU0sJRE8SZQcaLoX438vn9kyVSclZY5F9soVT3H E7Osd1CfrZgFA5ulfvRLQCi48eRsr53t81k= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 23sn93k5nh-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 25 Jun 2016 22:34:06 -0700 Received: from PRN-MBX01-4.TheFacebook.com ([169.254.3.129]) by PRN-CHUB09.TheFacebook.com ([fe80::b128:36fa:e69b:a338%12]) with mapi id 14.03.0294.000; Sat, 25 Jun 2016 22:34:05 -0700 From: Subodh Iyengar To: Martin Thomson , David Benjamin Thread-Topic: [TLS] Remove EncryptedExtensions from 0-RTT Thread-Index: AQHRzQCOMM43sQV4bE6+w7g/8bWsfp/3UVcAgABEEACAAAdqAIAAYskAgAM9t8I= Date: Sun, 26 Jun 2016 05:34:04 +0000 Message-ID: <974CF78E8475CD4CA398B1FCA21C8E995655BEB2@PRN-MBX01-4.TheFacebook.com> References: <20160623103546.GA5287@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-originating-ip: [192.168.52.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-26_03:, , signatures=0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove EncryptedExtensions from 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2016 05:34:09 -0000 Was there a compelling reason to not just put the ticket age in the clear i= n the CHLO field as @davidben alluded to before. It seems to make it much s= impler in general.=0A= =0A= With support for multiple tickets the server could issue multiple tickets a= t different times to make time correlation more difficult. The ticket seems= to be a more definitive identifier of the user than the time.=0A= =0A= Subodh=0A= ________________________________________=0A= From: TLS [tls-bounces@ietf.org] on behalf of Martin Thomson [martin.thomso= n@gmail.com]=0A= Sent: Thursday, June 23, 2016 1:59 PM=0A= To: David Benjamin=0A= Cc: tls@ietf.org=0A= Subject: Re: [TLS] Remove EncryptedExtensions from 0-RTT=0A= =0A= On 24 June 2016 at 01:05, David Benjamin wrote:=0A= > I don't think this matters. Just don't reuse tickets. But, if we cared, p= er=0A= > the "dumbest possible thing that might work" school of thought, we can=0A= > replace XOR with addition modulo 2^32. Now ticket reuse leaks the delta= =0A= > between two ClientHellos, which, precision aside, was already public=0A= > information from the receive time (with ticket as correlator). The timest= amp=0A= > of the ticket-minting connection is as secret as before.=0A= =0A= That sounds like fine reasoning to me. XOR or addition are both easy=0A= enough to specify.=0A= =0A= _______________________________________________=0A= TLS mailing list=0A= TLS@ietf.org=0A= https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_tls&d=3DCwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN= 7fQ&m=3Dryrz7HkNEVNbEb9yKsanQ1ZrOyiVdYuv8BDMJOF55s0&s=3DftTVBbImgxjUem3AV87= OqX3q_RKQKE1SJ7SGePOhWyc&e=3D=0A= From nobody Sun Jun 26 06:13:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9D212B04D for ; Sun, 26 Jun 2016 06:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVELHa2ujXOU for ; Sun, 26 Jun 2016 06:13:04 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1519112B017 for ; Sun, 26 Jun 2016 06:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1466946784; x=1498482784; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=yNpg1e8C5WGLJjSZ4Xr02mwALROGT3Fz55txh/dq17w=; b=Xy8O8AA3PbAXJS7nBjvHab2YwFhFDe2vxHj2XzW0Sjkl+PwqJmMfQ7X5 zL4jtdrBsHyi9891p9IlCkrcXmWHJAIzEbx6aP5e6tbPX83nWnA3Kpm3J BocrZKYGrgAjxLhBDYRukODogBmroHxKYdfyrEkaQew1H4gLOM21vOOnm uL3BPbbCA8rE6XNBx2kgyfOrC0HIheGPSkHJpSiPUSzwVpwgXgja6g3hg Qc77oWv+L+yEJ/uSUgEhE3V8OOWs2w5F4lvEYZTLntjuP97ZpOi712HP7 fc9NumqHz3hDQMWUUeHBlxRFqsxw+bxVJeSQnNFCfcTdheTCQnTxvnmjA g==; X-IronPort-AV: E=Sophos;i="5.26,531,1459771200"; d="scan'208";a="93307613" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Jun 2016 01:13:02 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Mon, 27 Jun 2016 01:13:02 +1200 From: Peter Gutmann To: "" Thread-Topic: Updated TLS-LTS draft posted Thread-Index: AdHPrHdP1mw8CLpOTwyvXTkqp2Q3gg== Date: Sun, 26 Jun 2016 13:13:01 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CB077A@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [TLS] Updated TLS-LTS draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2016 13:13:08 -0000 I've just posted the latest draft, as per Russ' comments and Hubert Kario's= =0A= suggestion this removes any mention of the term "profile" from the text, it= 's=0A= now called an update. It also clarifies some issues that were encountered= =0A= during testing, for example what happens during a rehandshake and how=0A= signalling of LTS vs. extended master secret and encrypt-then-MAC are handl= ed.=0A= =0A= There's also an open question as to what should happen when a suite with e.= g.=0A= SHA-512 is negotiated. The LTS mandatory suites all use SHA-256, but it's= =0A= possible to negotiate a suite with SHA-512 while still using LTS. Presumab= ly=0A= this means the hash size will change to 64 bytes rather than 32.=0A= =0A= Finally, there's now a LTS test server available for interop testing,=0A= temporarily using the next free extension value 26 until a value is=0A= permanently assigned for LTS use, see the draft for details.=0A= =0A= Peter.= From nobody Sun Jun 26 06:26:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C7512B055 for ; Sun, 26 Jun 2016 06:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzGXsEXF7Kco for ; Sun, 26 Jun 2016 06:26:21 -0700 (PDT) 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 39E9F12B050 for ; Sun, 26 Jun 2016 06:26:21 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id j2so203097393vkg.2 for ; Sun, 26 Jun 2016 06:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A71b8HCN59ro4iGwytdhheMzV9j9J+DhUmjU0HN6ibQ=; b=U7Tn0Sc3T1CXT90UZOhAaeCVO9Hc+91aCMjF3ki3+yXPfbPChISiY+saAY0YP/gyD6 xxccvRNIxNmKelzcXq0I8UAQZ7YU/6CdNjnj35iN4n4vbrlhLDcOoFHGbCyah2ZlAgKv VoobJXNucAvLSEUgJ+HLlm2/18m5I75xSoJmk= 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; bh=A71b8HCN59ro4iGwytdhheMzV9j9J+DhUmjU0HN6ibQ=; b=Xa+0epwCU4mOqWhFVbDiabgd6Tn+wGOI2vjM2BgzsPdaPzYu1s0gS7175BwAWxEo0y xd4kq3X2TtWvmoOo6W8F37O+0J/k/s4M+X20k61o3NtdfrfOdKnPEe9SK7ob7HgnVIpx r3psaYK+zfNcuJXV5afc29qJ1EdGkS/4PACdE0L77OadyWceSqZbf25qd3FmsUKnXtAq VBjuRHATc/d94swVvrxR39W4tFSuqP1opzwT5WdOtWpmdUsCQ+t4ihUgyBSzl07fgYEG 418zCU29aFiWkjyLUcIy6cJ+ecuMLkaozndWR2iLlzh4Jg5IpmXUvO4sJDWnHP1QDRH+ 8MCw== X-Gm-Message-State: ALyK8tIuQkpakzWFdv70931k6Zyp8UYwNKa++Gv5I5PUcvDxOWCj69UTkik+1dmKrFQI8BwL7xt2BNgjMC1Rkp17 X-Received: by 10.159.35.230 with SMTP id 93mr6540081uao.26.1466947580277; Sun, 26 Jun 2016 06:26:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.29.71 with HTTP; Sun, 26 Jun 2016 06:26:00 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CB077A@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4CB077A@uxcn10-5.UoA.auckland.ac.nz> From: Joseph Lorenzo Hall Date: Sun, 26 Jun 2016 09:26:00 -0400 Message-ID: To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Updated TLS-LTS draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2016 13:26:23 -0000 https://www.ietf.org/rfcdiff?url1=draft-gutmann-tls-lts-03&url2=draft-gutmann-tls-lts-04 On Sun, Jun 26, 2016 at 9:13 AM, Peter Gutmann wrote: > I've just posted the latest draft, as per Russ' comments and Hubert Kario's > suggestion this removes any mention of the term "profile" from the text, it's > now called an update. It also clarifies some issues that were encountered > during testing, for example what happens during a rehandshake and how > signalling of LTS vs. extended master secret and encrypt-then-MAC are handled. > > There's also an open question as to what should happen when a suite with e.g. > SHA-512 is negotiated. The LTS mandatory suites all use SHA-256, but it's > possible to negotiate a suite with SHA-512 while still using LTS. Presumably > this means the hash size will change to 64 bytes rather than 32. > > Finally, there's now a LTS test server available for interop testing, > temporarily using the next free extension value 26 until a value is > permanently assigned for LTS use, see the draft for details. > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 From nobody Sun Jun 26 09:34:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A6C12B012 for ; Sun, 26 Jun 2016 09:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83U2qg0GcFch for ; Sun, 26 Jun 2016 09:34:19 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7670A126B6D for ; Sun, 26 Jun 2016 09:34:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id CA1C21F1A; Sun, 26 Jun 2016 19:34:17 +0300 (EEST) 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 zURHvG4mB6K5; Sun, 26 Jun 2016 19:34:17 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 726652310; Sun, 26 Jun 2016 19:34:17 +0300 (EEST) Date: Sun, 26 Jun 2016 19:34:16 +0300 From: Ilari Liusvaara To: Subodh Iyengar Message-ID: <20160626163416.GA24381@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160623103546.GA5287@LK-Perkele-V2.elisa-laajakaista.fi> <974CF78E8475CD4CA398B1FCA21C8E995655BEB2@PRN-MBX01-4.TheFacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <974CF78E8475CD4CA398B1FCA21C8E995655BEB2@PRN-MBX01-4.TheFacebook.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove EncryptedExtensions from 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2016 16:34:22 -0000 On Sun, Jun 26, 2016 at 05:34:04AM +0000, Subodh Iyengar wrote: > Was there a compelling reason to not just put the ticket age in the > clear in the CHLO field as @davidben alluded to before. It seems to > make it much simpler in general. Unfortunately, just putting it in plain allows correlating sessions. That's the reason it is XOR'd currently, but the XOR probably will be changed to ADD32 to break correlation-to-parent (which is really nasty privacy-wise) in case of ticket reuse. > With support for multiple tickets the server could issue multiple > tickets at different times to make time correlation more difficult. > The ticket seems to be a more definitive identifier of the user > than the time. There is already support for that. But without fudging the times, correlation is still possible. -Ilari From nobody Sun Jun 26 18:33:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC2012D54C for ; Sun, 26 Jun 2016 18:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvqTF3eQzTeh for ; Sun, 26 Jun 2016 18:33:08 -0700 (PDT) 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 42EDB12D548 for ; Sun, 26 Jun 2016 18:33:08 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id p10so193097739qke.3 for ; Sun, 26 Jun 2016 18:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FvkSB1yRhOEZ467bavLWRJUfdQ0mcFwwpnSBqbg3seU=; b=n14XyLmjmOcfAvNOwys61Q2mQRxbvyLioWQLZx6a9U0oTyX8XT9BvTIiI4z3Oj5SLZ LMxNUmrnp4Y9KvyZHwNHqmgOFf7TAIhNiPRoVtD5vC9NfdtWXg01XAi1sZZPMpL2btFE TVwX4H/SRHC1xKJmRzGdCF6MSpu3xVKcbBYbQWqdyZtn4ERYD4dcHoD0YzrECc8qaPiU y1DNfvEHx6rwnP3Xs1FC1AtuekU6rCec6pp8gJoolbjAt2k8jOARJ8fHiTH0QiBPVIgk 6cRwRHf8JsIYnFGeJf54YwTsapTOo1BsPUag+cmUWVstrDNnOK4ElZ1xXoPqw12XHO7H I1uw== 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; bh=FvkSB1yRhOEZ467bavLWRJUfdQ0mcFwwpnSBqbg3seU=; b=kayc9LJtM4MeTm6E1iS9hj61ZELhkpmTOkn6+eQvg47j4nwPy5tDReof1m++9rUxme bJgUdpxU8QOYSvWydLl0t6lc6QJjZbrCi65rR2R5ogrdiHTtYuv+K7/UDoO8m0YiDrnk s+Sff9MK7c88zX8bqH6KdH6aIjpiXaldO6PjlodszBrSHvBUMG8QrQuI4TT0cxh90mf2 xc7vfwC6udNePn5BnDB0L3TM0oxJpt7QEw1CNvg9cfuoqY/MzspHcuE2M1sZxBZKb823 Y97auc8UgcuS9RGCpX0p90yT3I/i3WKoKmjoEjjr9tJoIt5HYixgvv6nq7fYqWZZRzG/ tN/g== X-Gm-Message-State: ALyK8tKIXzTj9kq1IK1Y6BzQfgeI86U9dEq+DEn1WZnOJhHuacDOgz7QYYMtmqJxRk3lsxbGSPyCMap1aWN9Jw== X-Received: by 10.55.118.196 with SMTP id r187mr19172494qkc.32.1466991187460; Sun, 26 Jun 2016 18:33:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.38 with HTTP; Sun, 26 Jun 2016 18:33:06 -0700 (PDT) In-Reply-To: <20160626163416.GA24381@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160623103546.GA5287@LK-Perkele-V2.elisa-laajakaista.fi> <974CF78E8475CD4CA398B1FCA21C8E995655BEB2@PRN-MBX01-4.TheFacebook.com> <20160626163416.GA24381@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Mon, 27 Jun 2016 11:33:06 +1000 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove EncryptedExtensions from 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 27 Jun 2016 01:33:10 -0000 On 27 June 2016 at 02:34, Ilari Liusvaara wrote: > That's the reason it is XOR'd currently, but the XOR probably will > be changed to ADD32 to break correlation-to-parent (which is really > nasty privacy-wise) in case of ticket reuse. Let's not make that probably. I've updated the PR. From nobody Mon Jun 27 07:37:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450C412D62A for ; Mon, 27 Jun 2016 07:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: 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_4yi1nLr9N6 for ; Mon, 27 Jun 2016 07:37:49 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 97DBA12D661 for ; Mon, 27 Jun 2016 07:35:58 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id m2so22590604qtd.1 for ; Mon, 27 Jun 2016 07:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=3jMSM24nMmgEUccmssAB52knDBap5P5ePix9p2STnL4=; b=DzJB2gFfwT5G5xgu0Tw527FJpEBQ7A5+dbLfHWO1mMRFmtM++vpE5sv0Jbev+mCQ6z zjIpdbX7U8mEEDwaVbNOt10pr8REmqdZoiQ73sgpZLgIODrYI6N4j3FhSt9Rt89z3q8e b1dnQ7vIxb3/dKHGbviHxSmBgoGD66WUzkLW0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=3jMSM24nMmgEUccmssAB52knDBap5P5ePix9p2STnL4=; b=CEYJeFrMhqSKBTvLmtrKGXYd6pHmQiR2R27RbAydj+zskq+geMHwVE1eIfsnWWIHvS 4AbZwvyAbq9GLFL/KtHDqEioV+oAi0BzGeQHcCHOv3EVXRpeIrHqsfA4FHbq3jsaB4DM H0UwlKmEq9IT+AQ5PKwgqJ3LqMJF7Tc8XvgRxi3S/F5e9Olte4LebnHFEDQRWDTaq1fc +uhxzObJJ1ywsKpocTHBtDdz1TyUpCwFO+oMvYM1Yi46lupYi0PB/SoOSxImlylxOivZ N4OhBHOATQ2iYhu9y3Isil4SEcBFtEbuArQL5qTcDhhpnpXBSnWaKXwMM1aKixRAWHrX IpTQ== X-Gm-Message-State: ALyK8tJ6IkAGbWfiA83vWEJVJziCsskM1iUK3TUChI9QK+PR6DLwjAlFnRPISW2q8noXPQ== X-Received: by 10.200.40.181 with SMTP id i50mr23955975qti.89.1467038157686; Mon, 27 Jun 2016 07:35:57 -0700 (PDT) Received: from [172.16.0.112] ([96.231.230.69]) by smtp.gmail.com with ESMTPSA id t1sm3534078qke.18.2016.06.27.07.35.56 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Jun 2016 07:35:57 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <061589B7-B7E0-43E2-BD0B-EA620E352CA5@sn3rd.com> Date: Mon, 27 Jun 2016 10:35:55 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] WG Status of draft-ietf-tls-pwd X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 27 Jun 2016 14:37:51 -0000 All, draft-ietf-tls-pwd [0] has been parked [1] by the WG chairs since late = 2013. It was parked=C2=9D by the WG chairs because there was no = consensus to move the document forward during WGLC [2][3]. However, = circumstances have changed namely the publication of Dragonfly Key = Exchange RFC [4] and the proposed changes to the IANA registration rules = for algorithm code points. In light of these two developments, the = chairs want to revisit this decision and would like to know before 12 = July if the WG wants to progress draft-ietf-pwd as a WG item to obtain = algorithm code points under the new rules [5]. Note that if the WG decides not to progress the draft the author will be = free to pursue other publication paths, e.g., through the AD or the ISE. Thanks, J&S [0] https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ [1] https://datatracker.ietf.org/doc/rfc6174/ [2] = https://mailarchive.ietf.org/arch/msg/tls/aYIXwO8l4K8XdvUoW9ysHT8WzA0 [3] = https://mailarchive.ietf.org/arch/msg/tls/Fep2-E7xQX7OQKzfxOoFInVFtm4 [4] https://datatracker.ietf.org/doc/rfc7664/ [5] Obviously, the draft needs to be revised in light of [3].= From nobody Mon Jun 27 08:11:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E0612D800 for ; Mon, 27 Jun 2016 08:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPzi6MVtVSnv for ; Mon, 27 Jun 2016 08:11:09 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c: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 BC84F12D5B5 for ; Mon, 27 Jun 2016 08:01:05 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id j3so22758011vkb.0 for ; Mon, 27 Jun 2016 08:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=jFkFxwyzAd/iDL6O6TvowUpUfQknSSRAcpAn+Ct8v8A=; b=hPm8YIba7GNnIstHIQjQkH8qsysJCFzEpOiDI5hSiEw1wzkj5iwIWZtR1KwGn3VvMf DdqmcGaBO+17SB5/+4Nc5B0LMK6j7l+O3Decn1PqfqWZvhSdyfl8X7sxnN+Gbuqt3cZO j1eaAkh5LK8SoDWjO2vVSAL0aA0IF3kej926fC7LsdTAviNgx6e6afH2IDdCn4CxXPUf oqozge2/RmCWWSJmvrSNTBdeDFn+aIgeGKTy8BRyfjwjljsmNvr8hzkNrIve3FG5i+U6 SArAiu7lo4qJWRksuhLre9/KybF3dl6GKTnpkyhHidEGD4KjDBqJs5coROxxnO/q9cKO Zycw== 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; bh=jFkFxwyzAd/iDL6O6TvowUpUfQknSSRAcpAn+Ct8v8A=; b=LeJAM41dZQHBIT79IQlmSHKJSipIqz9NLHrZRBaUFPW1UddDlfHshdAWhmUQzkHngY kFuMXADrHDX6bL3PfFbXcb8QpSzXygWUQn0tbK+pcjpkCWv44nnTFwlu1fM/XFdhAJXv rumbz4xStFNJt0Tb4VQLIyRHOanBgh5aW7ue9JxRGLWl5Ir1LTKsLWBEjqHZWzdYk+1a VSwZfxqxHSaxUddRNuwWRjdD97REt8CQG3fFJce6iXmnHPqnoJCQZoJ5YlMAbW3aSIQi nNaNg9DWJuUOcgU3MGTtWuZU3XOadb8sBCRcBdyC6oIvZqhdqzH71yIdwSaXFypcZqtt +u+g== X-Gm-Message-State: ALyK8tKnYfTC0CWyJ43fSu1LJhtO4SLvdsGtt1QWR1mxNzlFOZI1g7MqwkHw3W2mANVc4WavFmLr6d3RS1cUJg== MIME-Version: 1.0 X-Received: by 10.176.0.56 with SMTP id 53mr8426214uai.87.1467039664456; Mon, 27 Jun 2016 08:01:04 -0700 (PDT) Received: by 10.159.35.65 with HTTP; Mon, 27 Jun 2016 08:01:03 -0700 (PDT) Received: by 10.159.35.65 with HTTP; Mon, 27 Jun 2016 08:01:03 -0700 (PDT) In-Reply-To: <061589B7-B7E0-43E2-BD0B-EA620E352CA5@sn3rd.com> References: <061589B7-B7E0-43E2-BD0B-EA620E352CA5@sn3rd.com> Date: Mon, 27 Jun 2016 08:01:03 -0700 Message-ID: From: Watson Ladd To: Sean Turner Content-Type: multipart/alternative; boundary=001a113db6da124b3a053643cadf Archived-At: Cc: "" Subject: Re: [TLS] WG Status of draft-ietf-tls-pwd X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 27 Jun 2016 15:11:13 -0000 --001a113db6da124b3a053643cadf Content-Type: text/plain; charset=UTF-8 On Jun 27, 2016 7:38 AM, "Sean Turner" wrote: > > All, > > draft-ietf-tls-pwd [0] has been parked [1] by the WG chairs since late 2013. It was parked by the WG chairs because there was no consensus to move the document forward during WGLC [2][3]. However, circumstances have changed namely the publication of Dragonfly Key Exchange RFC [4] and the proposed changes to the IANA registration rules for algorithm code points. In light of these two developments, the chairs want to revisit this decision and would like to know before 12 July if the WG wants to progress draft-ietf-pwd as a WG item to obtain algorithm code points under the new rules [5]. Things have also changed in that JPAKE2 has a security proof IIUC. While the CFRG PAKE process has slowed, there are still a number of competing options here and I don't think "all of the above" is the right answer. > > Note that if the WG decides not to progress the draft the author will be free to pursue other publication paths, e.g., through the AD or the ISE. > > Thanks, > > J&S > > [0] https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ > [1] https://datatracker.ietf.org/doc/rfc6174/ > [2] https://mailarchive.ietf.org/arch/msg/tls/aYIXwO8l4K8XdvUoW9ysHT8WzA0 > [3] https://mailarchive.ietf.org/arch/msg/tls/Fep2-E7xQX7OQKzfxOoFInVFtm4 > [4] https://datatracker.ietf.org/doc/rfc7664/ > [5] Obviously, the draft needs to be revised in light of [3]. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --001a113db6da124b3a053643cadf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 27, 2016 7:38 AM, "Sean Turner" <sean@sn3rd.com> wrote:
>
> All,
>
> draft-ietf-tls-pwd [0] has been parked [1] by the WG chairs since late= 2013.=C2=A0 It was parked=C2=A0 by the WG chairs because there was no cons= ensus to move the document forward during WGLC [2][3]. However, circumstanc= es have changed namely the publication of Dragonfly Key Exchange RFC [4] an= d the proposed changes to the IANA registration rules for algorithm code po= ints.=C2=A0 In light of these two developments, the chairs want to revisit = this decision and would like to know before 12 July if the WG wants to prog= ress draft-ietf-pwd as a WG item to obtain algorithm code points under the = new rules [5].

Things have also changed in that JPAKE2 has a security proof= IIUC. While the CFRG PAKE process has slowed, there are still a number of = competing options here and I don't think "all of the above" i= s the right answer.

>
> Note that if the WG decides not to progress the draft the author will = be free to pursue other publication paths, e.g., through the AD or the ISE.=
>
> Thanks,
>
> J&S
>
> [0] h= ttps://datatracker.ietf.org/doc/draft-ietf-tls-pwd/
> [1] https://data= tracker.ietf.org/doc/rfc6174/
> [2] https://mailarchive.ietf.org/arch/msg/tls/aYIXwO8l4K8XdvUoW= 9ysHT8WzA0
> [3] https://mailarchive.ietf.org/arch/msg/tls/Fep2-E7xQX7OQKzfx= OoFInVFtm4
> [4] https://data= tracker.ietf.org/doc/rfc7664/
> [5] Obviously, the draft needs to be revised in light of [3].
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--001a113db6da124b3a053643cadf-- From nobody Mon Jun 27 09:58:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3DF12D860 for ; Mon, 27 Jun 2016 09:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIVSqIq19pJd for ; Mon, 27 Jun 2016 09:58:09 -0700 (PDT) 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 1AB6412D825 for ; Mon, 27 Jun 2016 09:58:09 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id a125so15877638qkc.2 for ; Mon, 27 Jun 2016 09:58:09 -0700 (PDT) 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; bh=J2HcAunxRUuMeKWniBsj/9RlM+F6cJh2clAOggKK5Go=; b=ttfjixEJoPDTZZvVnMtcPKD6YMcQPCak/LaGhwrihDgWjRZKu9wPlaIMvmASCV1ms1 JloyzXJ8yuUUPXcJiaaCF4LsfE8+yHimcPMxQhkbMWWoKhNeR5eNy/0JCgc7OUEFAx+7 n56fk9OP24kTaLjY3iP7WjvzvUVtMXvZyDRvSloLH/6f58qyKlyXiekmvNxdo2sVkOJg BN1E6I0yzGVDcclgjZWkvu2ZfYTG5Pc2wA3VDScRpwciwUP05iZnwqJXFCa+oSUnjE9H kgyY08NyWZxseJJ50aJm/XccsbBZO804c1/SVkKNZSe7uV3XiLEDVXunrvqElWd6DsOK 9dzQ== 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; bh=J2HcAunxRUuMeKWniBsj/9RlM+F6cJh2clAOggKK5Go=; b=Oc7NjBHmJdqwAlhU3khBTY0pPivEg3Qa3dayHcAcVDNw/Q8p6WGpZ0bcujUmc2MR7H 2ax886W/gKW7PAY+/1aqc4g1BWxtN4wZ2y4f6NsMJH2ZustcHMB2QMQv0IhZ9mZOm3Wt UBqVa+se8UTarNxcQDFqrKCg7vYblkzEdiOBx+gGBxywlfnLFOhy2MqlhrsLBIIV/nv4 qMAQ059f2sYaQatteGnK31t7mz5MEW595+6NV5V2FBKpy8GS4PauRs9CDPbVf2xCHWts TDuzsorLhXBv33Jx7fi+TBO7jOp+MFn6g2tiOdwpMfPB31N6OroMpgxjr+bUVH57kLs2 9dzA== X-Gm-Message-State: ALyK8tIIcM/zu3AVUg/iwlxlJEp8lUrEnqP6Iz3qrvNhV+5z86BVb44BeT0SaS2+AEvdrpXoFC+nQR+BJq9F4A== X-Received: by 10.129.52.84 with SMTP id b81mr12597219ywa.8.1467046688276; Mon, 27 Jun 2016 09:58:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.7 with HTTP; Mon, 27 Jun 2016 09:57:28 -0700 (PDT) In-Reply-To: References: <061589B7-B7E0-43E2-BD0B-EA620E352CA5@sn3rd.com> From: Eric Rescorla Date: Mon, 27 Jun 2016 09:57:28 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a11406f0ab9a6630536456cbd Archived-At: Cc: "" Subject: Re: [TLS] WG Status of draft-ietf-tls-pwd X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 27 Jun 2016 16:58:12 -0000 --001a11406f0ab9a6630536456cbd Content-Type: text/plain; charset=UTF-8 I don't think we should take this as a WG work item. I'd be happy for Dan to get a code point under the new rules, which I would also be happy to consider effective as of now. -Ekr On Mon, Jun 27, 2016 at 8:01 AM, Watson Ladd wrote: > > On Jun 27, 2016 7:38 AM, "Sean Turner" wrote: > > > > All, > > > > draft-ietf-tls-pwd [0] has been parked [1] by the WG chairs since late > 2013. It was parked by the WG chairs because there was no consensus to > move the document forward during WGLC [2][3]. However, circumstances have > changed namely the publication of Dragonfly Key Exchange RFC [4] and the > proposed changes to the IANA registration rules for algorithm code points. > In light of these two developments, the chairs want to revisit this > decision and would like to know before 12 July if the WG wants to progress > draft-ietf-pwd as a WG item to obtain algorithm code points under the new > rules [5]. > > Things have also changed in that JPAKE2 has a security proof IIUC. While > the CFRG PAKE process has slowed, there are still a number of competing > options here and I don't think "all of the above" is the right answer. > > > > > Note that if the WG decides not to progress the draft the author will be > free to pursue other publication paths, e.g., through the AD or the ISE. > > > > Thanks, > > > > J&S > > > > [0] https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ > > [1] https://datatracker.ietf.org/doc/rfc6174/ > > [2] > https://mailarchive.ietf.org/arch/msg/tls/aYIXwO8l4K8XdvUoW9ysHT8WzA0 > > [3] > https://mailarchive.ietf.org/arch/msg/tls/Fep2-E7xQX7OQKzfxOoFInVFtm4 > > [4] https://datatracker.ietf.org/doc/rfc7664/ > > [5] Obviously, the draft needs to be revised in light of [3]. > > _______________________________________________ > > 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 > > --001a11406f0ab9a6630536456cbd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think we should take this as a WG work item. I= 'd be happy for Dan to get a code point
under the new rules, which = I would also be happy to consider effective as of now.

-Ekr


On Mon, Jun 27, 2016 at 8:01 AM, Watson Ladd <w= atsonbladd@gmail.com> wrote:


On Jun 27, 2016 7:38 AM, "Sean Turner" <sean@sn3rd.com> wrote:
>
> All,
>
> draft-ietf-tls-pwd [0] has been parked [1] by the WG chairs since late= 2013.=C2=A0 It was parked=C2=A0 by the WG chairs because there was no cons= ensus to move the document forward during WGLC [2][3]. However, circumstanc= es have changed namely the publication of Dragonfly Key Exchange RFC [4] an= d the proposed changes to the IANA registration rules for algorithm code po= ints.=C2=A0 In light of these two developments, the chairs want to revisit = this decision and would like to know before 12 July if the WG wants to prog= ress draft-ietf-pwd as a WG item to obtain algorithm code points under the = new rules [5].

Things have also changed in that JPAKE2 has a securit= y proof IIUC. While the CFRG PAKE process has slowed, there are still a num= ber of competing options here and I don't think "all of the above&= quot; is the right answer.

>
> Note that if the WG decides not to progress the draft the author will = be free to pursue other publication paths, e.g., through the AD or the ISE.=
>
> Thanks,
>
> J&S
>
> [0] https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ > [1] https://datatracker.ietf.org/doc/rfc6174/
> [2] https://mailarchive.ietf.org/arch/msg/tls= /aYIXwO8l4K8XdvUoW9ysHT8WzA0
> [3] https://mailarchive.ietf.org/arch/msg/tls= /Fep2-E7xQX7OQKzfxOoFInVFtm4
> [4] https://datatracker.ietf.org/doc/rfc7664/
> [5] Obviously, the draft needs to be revised in light of [3].
> _______________________________________________
> 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


--001a11406f0ab9a6630536456cbd-- From nobody Tue Jun 28 06:20:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50EA12B054; Tue, 28 Jun 2016 06:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrMgxFX-4MnU; Tue, 28 Jun 2016 06:20:01 -0700 (PDT) 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 BDA6112DBF6; Tue, 28 Jun 2016 06:19:48 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-25-577275edbd1e Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id EA.22.27088.DE572775; Tue, 28 Jun 2016 15:04:45 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.294.0; Tue, 28 Jun 2016 15:04:44 +0200 To: IETF AVTCore WG , "tram@ietf.org" , , "tls@ietf.org" , "mmusic (E-mail)" , "draft-ietf-avtcore-rfc5764-mux-fixes@ietf.org" From: Magnus Westerlund Message-ID: Date: Tue, 28 Jun 2016 15:04:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUyM2K7nO7b0qJwg/55ghYve1ayWxz4OJXZ 4tuFWoupyx+zWHw638Vo8WHtBTYHNo8lS34yBTBGcdmkpOZklqUW6dslcGXMWPSEreA4V8Wt 3dINjKc5uhg5OSQETCSOtX1gh7DFJC7cW8/WxcjFISRwhFHi2LFGVghnOaPEh197GEEcEYF/ jBIfN95kAWlhE7CQuPmjkQ3EFhZwlTj89jojiM0rYC/RvnILmM0ioCqxfspVsBWiAjESjbcP s0PUCEqcnPkEaA4HBzNQ/YOtZSBhZgF5ieats5lBbCEBbYmGpg7WCYx8s5B0zELomIWkYwEj 8ypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwAA8uOW3wQ7Gl88dDzEKcDAq8fA+WFgYLsSa WFZcmXuIUYKDWUmEd2NxUbgQb0piZVVqUX58UWlOavEhRmkOFiVxXv+XiuFCAumJJanZqakF qUUwWSYOTqkGxjXpU/u8j22docrEXHgla4/f1bANt81yhb2iAr4rZbps3Pb4qMmluVEKUtPt Wc64OO+60LN8zfPGiV6Hfh/bVfZdUfDp1+A/fI6Tjf53zpKpnutiuWIeozgz/0/NoNVTI4Me uT1OCGx+GndKWJdhygfH7/NF+R4539xhu96P2+tx37/auXGLViixFGckGmoxFxUnAgCr17fD PAIAAA== Archived-At: Subject: [TLS] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Jun 2016 13:20:09 -0000 WGs, I as WG chair earlier made a mistake in failing to include the relevant WGs in our previous WG last call. Thus I would like to make a one week confirmation call on the content of draft-ietf-avtcore-rfc5764-mux-fixes-09 prior to publication request. https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/ TRAM WG: Please check that you are okay with the restrictions and updates to the TURN channel allocations as well as STUN Method restrictions. TLS WG: I believe you are satisfied with the impact on the TLS IANA registry after previous discussions, but you are welcome to confirm this. ICE: For your information as this impacts protocol mechanism your are dependent on. MMUSIC: For your information due to some notes in regards to BUNDLE and RFC7345. Please provide any feedback by 5th of July. cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jun 28 07:35:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240B912D1A6; Tue, 28 Jun 2016 07:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC2OEfy-XCii; Tue, 28 Jun 2016 07:35:10 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E4D12D1B9; Tue, 28 Jun 2016 07:35:08 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-73-57728b1a87e4 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E9.6B.18043.A1B82775; Tue, 28 Jun 2016 16:35:06 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.294.0; Tue, 28 Jun 2016 16:35:06 +0200 To: IETF AVTCore WG , "tram@ietf.org" , , "tls@ietf.org" , "mmusic (E-mail)" , "draft-ietf-avtcore-rfc5764-mux-fixes@ietf.org" References: From: Magnus Westerlund Message-ID: <10a73efe-2e50-77ed-e78f-298d388efb47@ericsson.com> Date: Tue, 28 Jun 2016 16:35:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM2K7oq5Ud1G4waPthhYve1ayWxz4OJXZ 4tuFWoupyx+zWHw638Vo8WHtBTYHNo8lS34yBTBGcdmkpOZklqUW6dslcGVsWbuTveCdRMWK td2MDYwPhLsYOTkkBEwkPszYzgphi0lcuLeeDcQWEjjCKPFpXX0XIxeQvZxR4s3VtcxdjBwc wgIhEsf3J4HERQT+MUp83HiTBaLBXuLXzkZmEJtNwELi5o9GsEG8QPETb74zgvSyCKhK3Pge CxIWFYiRaLx9mB2iRFDi5MwnYGM4BRwkjv/cwAJSzgzU+mBrGUiYWUBeonnrbGaITdoSDU0d rBMYBWYh6Z6F0DELSccCRuZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIHBenDLb6sdjAef Ox5iFOBgVOLhfbCwMFyINbGsuDL3EKMEB7OSCK9nV1G4EG9KYmVValF+fFFpTmrxIUZpDhYl cV7/l4rhQgLpiSWp2ampBalFMFkmDk6pBsYIVu65q/fbrOl8Y5aWzliVlNs27diE1suTYqw5 n0zP+im5f/U6tSjjCPZzWrNSDLYF9R32nda0ojqsYNvfCbN5VxQd31Gqlm7WYG948ZHo2Udz X4gcVwpbn+A7u+Lk829sTheLGT7ZRgTn6qUxfVrtEsq9um6Ly13Vd49EpxtmOXi5HGqY7q/E UpyRaKjFXFScCADk8d++UgIAAA== Archived-At: Subject: Re: [TLS] [MMUSIC] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Jun 2016 14:35:12 -0000 Authors and WGs, In my review for the publication writeup I did spot some issues in the draft. Please consider the following issues: 1. Abstract: With the addition of the ZRTP the abstract should benefit from being updated. The ZRTP protocol being possible to multiplex is missing as well as that there are now 4 issues. 2. Abstract contains [ref] to RFC 5764. This is an ID nit. 3. Section 1. The introduction is not explicitly saying that it updates RFC 5764. I think that can be put as a sentence after: This is achieved by modifying the IANA registries with instructions for coordination between the protocols at risk. 4. Reference ID-nits: == Outdated reference: A later version (-31) exists of draft-ietf-mmusic-sdp-bundle-negotiation-23 5. Section 2: ID-nits complains about the modified boilerplate for the RFC2119 text. First of all one usually don't cut down the list to only the used ones. The requirement on all caps ones I am very divided about. I do have a preference for unmodified boilerplate, this as I otherwise have to explain in the write-up the ID-nit. 6. Section 6: In order to prevent future documents from assigning values from the unused range to a new protocol, this document modifies the RFC 5764 demultiplexing algorithm to properly account for TURN channels by allocating the values from 64 to 79 for this purpose. I think this text fails to be explicit about that this restricts the TURN Channel space to a more limited set of possible channels when the TURN client does the channel binding request. Thus affecting the TURN channel allocation algorithm in the client implementations, at least when used in combination of muxing. Based on this and the fact that this specification changes the IANA registrations performed by RFC5766, I think this document to have "Updates" for RFC5766 also. So please add that in header, abstract and introduction. 7. Updates RFC5389: Looking at the impact also on the STUN protocol I would also think that this requires and "Updates" also for RFC 5389. 8. Section 10.3: The IANA registry name is not the correct one. The IANA page says that the registry name is: Traversal Using Relays around NAT (TURN) Channel Numbers http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml#turn-channel Please update. 9. Section 12.2: The reference to ZRTP [RFC6189] is likely in the wrong category, at the same time moving this to a normative one creates a downref. I guess it one that has to be accepted in this case. I suggest that you move it to the normative references. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jun 28 10:02:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1284312D5BC for ; Tue, 28 Jun 2016 10:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.348 X-Spam-Level: X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIXCI2fUx5TT for ; Tue, 28 Jun 2016 10:02:00 -0700 (PDT) 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 15F1712D5BE for ; Tue, 28 Jun 2016 10:02:00 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2084F3F723; Tue, 28 Jun 2016 17:01:59 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-109.brq.redhat.com [10.34.0.109]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5SH1u6A000798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jun 2016 13:01:57 -0400 From: Hubert Kario To: tls@ietf.org Date: Tue, 28 Jun 2016 19:01:51 +0200 Message-ID: <2279135.STQlCAVDxp@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.13-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <20160623155339.GA5659@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160623155339.GA5659@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2529696.YKF4mbO3gX"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 28 Jun 2016 17:01:59 +0000 (UTC) Archived-At: Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Jun 2016 17:02:02 -0000 --nextPart2529696.YKF4mbO3gX Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 23 June 2016 18:53:39 Ilari Liusvaara wrote: > On Thu, Jun 23, 2016 at 07:26:37AM -0700, Watson Ladd wrote: > > On Tue, Jun 21, 2016 at 8:58 PM, Martin Thomson > > wrote: > > > On 22 June 2016 at 12:01, Watson Ladd wro= te: > > >> Why isn't 0-RTT an extension in the Client Hello to deal with th= is? > > > > > > You can't stream extensions, which unfortunately is required give= n how > > > most software interacts with their TLS stack. > >=20 > > A few months ago we had a lengthy discussion on the list and at TRO= N > > about how risky 0-RTT is. This culminated in the idea that 0RTT dat= a > > should be provided through a distinct channel to the application, > > along with feedback about whether it was not accepted. If we're > > willing to change the interaction pattern to support that, we can > > accommodate using 0RTT as an extension by gathering it all and send= ing > > when the handshake happens. But it sounds like you are discussing a= > > design where the handshake fakes completion if 0-RTT is on, and at > > some point later "well, i didn't actually send the data you wanted > > to". Or am I missing something about the API design that is motivat= ing > > this streaming approach? >=20 > Sticking 0-RTT data into ClientHello also has the following problems:= > - One needs to mangle ClientHello (strip an extension on receiver sid= e) > to obtain hash suitable for key derivation for 0-RTT. To do it any > other way either doesn't work, or are cryptographically quite risky= . > - It bloats ClientHello, something you rather not bloat, especially > with DTLS. here's a crazy idea: - introduce a new extension which has meaning of "more data follows" - if the server finds it, it expects another Handshake Protocol messag= e from the client - the client sends a new "ClientHelloExtension" message that includes additional data, in practice it's continuation of the extension list= (just let's use 3 byte length fields in the structure) the obvious downside is, that TLSv1.2 servers do not support it now the upsides are: * TLSv1.2 servers can be fairly easily updated to support it but ignore it (just feed the next message to handshake hash, but = not interpret it) - that fixes the upgrade scenario and allows the proce= ss to be performed in two steps, either of which can then be safely revers= ed * makes it possible in the future, if we are forced to, support post q= uantum crypto that requires key shares that won't fit in current extensions= field =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 --nextPart2529696.YKF4mbO3gX 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 iQIcBAABCgAGBQJXcq1/AAoJEJKo0bgB0vX1zdsP/0byWxeNtvSo/TcAMTbOwl8q P0MSGh4Y7EZnBybjuby1PyHqfxaohvocp3NGGHgOMCp5mQmhGVpHMrfiivkCwYkK Yyn/v4L/JHvZ/2v3bMiXnO+67DkefJUK1pQOG2d9mSEn7MSJ744uki68c+2GJ8Z1 RsvZzn/eVGoVj/7tZaKoGcb3rE3XRFHosunN/uVJ4Z+EmNlvwKi5Ek3dX0ZHYtJH 4P4mIbraFocRYti0GyMUhLgAM2GiDPe/8Z2Xxr/T55frtbH658tA+jJ/I8x57v4C aFLTgobd2tESgE1fCO9HJIKLgSgeFq6qwYWiGJO9gDFLf0Ayywr+K0nmJ6OCur/y SX2GraRKjBEV+YvRnOTbhFTcQ+nkDr1hATkBKmyX5F4N4D354M5+3UM7lonqqo6Z Ete32e+aQY/lGF5cy8h/KpZuZlSdtvyzJbAb0924+d6wjMHze/sp0Rt5xdBNZc42 yoPAQ4UcTbrI4pVu1SoQrSMd4Tc1lIO/tvor1ySRv/IxAcXoIj9CnN2bFaBeiNsC 53KagoJCc+JnZx2Fy2mkbzjJ8dcdhSvjo4s4jQSfFlXeTx1uIl3KX8Wkf0tM86+I Y6WRdPkBuW7AgpbunAXinKGIU34HX/aSS/sV2d/OAfoPFSs9dD/NBUguP6+UbNhV 7g9WqI097iQF3n7dgiLn =sfoa -----END PGP SIGNATURE----- --nextPart2529696.YKF4mbO3gX-- From nobody Tue Jun 28 10:41:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574C512D10D for ; Tue, 28 Jun 2016 10:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IJ9mtd9dHHQ for ; Tue, 28 Jun 2016 10:40:55 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 7EABC12B012 for ; Tue, 28 Jun 2016 10:40:55 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id a5so98540870ita.1 for ; Tue, 28 Jun 2016 10:40:55 -0700 (PDT) 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; bh=vUzGAej4V3jzF8SXSmlsh0M79scyDS6TTXuC7p4IRrs=; b=Nsmk8ivQvVYB5VSAY0qarTh+MYm9xvtUI5YBTVoOoXMGnLK7H7rSc+4GuJL6eaSyyJ VpIG7rBtX3jA1cYcmcokUv0j/O/c1dRenrTsotGuSVKovO55rZoleWJjUHvI0Zk9UINF hCFKe/tC+ednkVvZqhQe7RKFgA4a3QBTkUqJg= 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; bh=vUzGAej4V3jzF8SXSmlsh0M79scyDS6TTXuC7p4IRrs=; b=C13JRotlcvNsGMzGX2C3axJIsZw2XL0KGV7pLcLMhm8dLJPXmeEZTkGpnj25d+Tqet IDUsxhVpqh9iQbUMbsXHcvq5ny89ZK9Zwt57Ntp56p4ISj4C7zrLBWEDIcJViMZFnEFi Rnm8MW7JXgrl0trf4pTiDZRhBvFYkZ4rlgiWAryBMU9MlJLOM9MXL4ezipMoTDNIFsuc W+KzxhmJc+IwX7Wsejssh2oyPZUqcGUlw9oDT1trl1/8olDTV1rqM9+Ze5966a5vwyGC sX9FFNbA4Y3bm20w2KisS+8wJUV88zFyf26h6JnDb2UMrcKfxmYcOvZGEijkiETE4I/e 6YsQ== X-Gm-Message-State: ALyK8tIV0TPqFcDCXeSvj4gcaHE1PTKD3aeZjU7S+oc4BPt5XeAHp4W5AmMTHHlYZcyZmjFfPPWnk3CjmLbE7UvG X-Received: by 10.36.227.67 with SMTP id d64mr5150231ith.18.1467135654746; Tue, 28 Jun 2016 10:40:54 -0700 (PDT) MIME-Version: 1.0 References: <20160623155339.GA5659@LK-Perkele-V2.elisa-laajakaista.fi> <2279135.STQlCAVDxp@pintsize.usersys.redhat.com> In-Reply-To: <2279135.STQlCAVDxp@pintsize.usersys.redhat.com> From: David Benjamin Date: Tue, 28 Jun 2016 17:40:45 +0000 Message-ID: To: Hubert Kario , tls@ietf.org Content-Type: multipart/alternative; boundary=94eb2c111ada8a3aaa05365a23a9 Archived-At: Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Jun 2016 17:40:58 -0000 --94eb2c111ada8a3aaa05365a23a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 28, 2016 at 1:02 PM Hubert Kario wrote: > On Thursday 23 June 2016 18:53:39 Ilari Liusvaara wrote: > > On Thu, Jun 23, 2016 at 07:26:37AM -0700, Watson Ladd wrote: > > > On Tue, Jun 21, 2016 at 8:58 PM, Martin Thomson > > > wrote: > > > > On 22 June 2016 at 12:01, Watson Ladd wrote= : > > > >> Why isn't 0-RTT an extension in the Client Hello to deal with this= ? > > > > > > > > You can't stream extensions, which unfortunately is required given > how > > > > most software interacts with their TLS stack. > > > > > > A few months ago we had a lengthy discussion on the list and at TRON > > > about how risky 0-RTT is. This culminated in the idea that 0RTT data > > > should be provided through a distinct channel to the application, > > > along with feedback about whether it was not accepted. If we're > > > willing to change the interaction pattern to support that, we can > > > accommodate using 0RTT as an extension by gathering it all and sendin= g > > > when the handshake happens. But it sounds like you are discussing a > > > design where the handshake fakes completion if 0-RTT is on, and at > > > some point later "well, i didn't actually send the data you wanted > > > to". Or am I missing something about the API design that is motivatin= g > > > this streaming approach? > > > > Sticking 0-RTT data into ClientHello also has the following problems: > > - One needs to mangle ClientHello (strip an extension on receiver side) > > to obtain hash suitable for key derivation for 0-RTT. To do it any > > other way either doesn't work, or are cryptographically quite risky. > > - It bloats ClientHello, something you rather not bloat, especially > > with DTLS. > > here's a crazy idea: > > - introduce a new extension which has meaning of "more data follows" > - if the server finds it, it expects another Handshake Protocol message > from the client > - the client sends a new "ClientHelloExtension" message that includes > additional data, in practice it's continuation of the extension list > (just let's use 3 byte length fields in the structure) > > the obvious downside is, that TLSv1.2 servers do not support it now > > the upsides are: > * TLSv1.2 servers can be fairly easily updated to support > it but ignore it (just feed the next message to handshake hash, but no= t > interpret it) - that fixes the upgrade scenario and allows the process > to > be performed in two steps, either of which can then be safely reversed > We could just as easily update TLS 1.2 servers to know how to skip early data. Or, better yet, update those servers to TLS 1.3. The problem is requiring those servers to update to begin with. At least for browsers and the web, any solution that assumes we will get the entire install-base updated in bounded time won't work. It took us 15 years to get rid of SSL 3.0 and even then, with a widely publicized protocol bug and a cutesy name, it was *still* a hassle and took a lot out of metaphorical breakage budget. David > * makes it possible in the future, if we are forced to, support post > quantum > crypto that requires key shares that won't fit in current extensions > field > > -- > 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 > --94eb2c111ada8a3aaa05365a23a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 28= , 2016 at 1:02 PM Hubert Kario <hka= rio@redhat.com> wrote:
On Th= ursday 23 June 2016 18:53:39 Ilari Liusvaara wrote:
> On Thu, Jun 23, 2016 at 07:26:37AM -0700, Watson Ladd wrote:
> > On Tue, Jun 21, 2016 at 8:58 PM, Martin Thomson
> > <martin.thomson@gmail.com> wrote:
> > > On 22 June 2016 at 12:01, Watson Ladd <watsonbladd@gmail.com> wrot= e:
> > >> Why isn't 0-RTT an extension in the Client Hello to = deal with this?
> > >
> > > You can't stream extensions, which unfortunately is requ= ired given how
> > > most software interacts with their TLS stack.
> >
> > A few months ago we had a lengthy discussion on the list and at T= RON
> > about how risky 0-RTT is. This culminated in the idea that 0RTT d= ata
> > should be provided through a distinct channel to the application,=
> > along with feedback about whether it was not accepted. If we'= re
> > willing to change the interaction pattern to support that, we can=
> > accommodate using 0RTT as an extension by gathering it all and se= nding
> > when the handshake happens. But it sounds like you are discussing= a
> > design where the handshake fakes completion if 0-RTT is on, and a= t
> > some point later "well, i didn't actually send the data = you wanted
> > to". Or am I missing something about the API design that is = motivating
> > this streaming approach?
>
> Sticking 0-RTT data into ClientHello also has the following problems:<= br> > - One needs to mangle ClientHello (strip an extension on receiver side= )
>=C2=A0 =C2=A0to obtain hash suitable for key derivation for 0-RTT. To d= o it any
>=C2=A0 =C2=A0other way either doesn't work, or are cryptographicall= y quite risky.
> - It bloats ClientHello, something you rather not bloat, especially >=C2=A0 =C2=A0with DTLS.

here's a crazy idea:

=C2=A0- introduce a new extension which has meaning of "more data foll= ows"
=C2=A0- if the server finds it, it expects another Handshake Protocol messa= ge
=C2=A0 =C2=A0from the client
=C2=A0- the client sends a new "ClientHelloExtension" message tha= t includes
=C2=A0 =C2=A0additional data, in practice it's continuation of the exte= nsion list
=C2=A0 =C2=A0(just let's use 3 byte length fields in the structure)

the obvious downside is, that TLSv1.2 servers do not support it now

the upsides are:
=C2=A0* TLSv1.2 servers can be fairly easily updated to support
=C2=A0 =C2=A0it but ignore it (just feed the next message to handshake hash= , but not
=C2=A0 =C2=A0interpret it) - that fixes the upgrade scenario and allows the= process to
=C2=A0 =C2=A0be performed in two steps, either of which can then be safely = reversed

We could just as easily update= TLS 1.2 servers to know how to skip early data. Or, better yet, update tho= se servers to TLS 1.3.

The problem is requiring th= ose servers to update to begin with. At least for browsers and the web, any= solution that assumes we will get the entire install-base updated in bound= ed time won't work. It took us 15 years to get rid of SSL 3.0 and even = then, with a widely publicized protocol bug and a cutesy name, it was *stil= l* a hassle and took a lot out of metaphorical breakage budget.
<= br>
David
=C2=A0
=C2=A0* makes it possible in the future, if we are forced to, support post = quantum
=C2=A0 =C2=A0crypto that requires key shares that won't fit in current = extensions field

--
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
--94eb2c111ada8a3aaa05365a23a9-- From nobody Tue Jun 28 11:26:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6DC12D528 for ; Tue, 28 Jun 2016 11:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.348 X-Spam-Level: X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk8ZECFcDt7U for ; Tue, 28 Jun 2016 11:26:34 -0700 (PDT) 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 0DDDD12D1D7 for ; Tue, 28 Jun 2016 11:26:33 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 762CA80B56; Tue, 28 Jun 2016 18:26:33 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-109.brq.redhat.com [10.34.0.109]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5SIQVaF018241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jun 2016 14:26:33 -0400 From: Hubert Kario To: David Benjamin Date: Tue, 28 Jun 2016 20:26:25 +0200 Message-ID: <3937856.RExby9y8oT@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.13-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: References: <2279135.STQlCAVDxp@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2318608.QtIYAy4oZL"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 28 Jun 2016 18:26:33 +0000 (UTC) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Jun 2016 18:26:43 -0000 --nextPart2318608.QtIYAy4oZL Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 28 June 2016 17:40:45 David Benjamin wrote: > On Tue, Jun 28, 2016 at 1:02 PM Hubert Kario wrot= e: >=20 > > On Thursday 23 June 2016 18:53:39 Ilari Liusvaara wrote: > > > On Thu, Jun 23, 2016 at 07:26:37AM -0700, Watson Ladd wrote: > > > > On Tue, Jun 21, 2016 at 8:58 PM, Martin Thomson > > > > wrote: > > > > > On 22 June 2016 at 12:01, Watson Ladd = wrote: > > > > >> Why isn't 0-RTT an extension in the Client Hello to deal wit= h this? > > > > > > > > > > You can't stream extensions, which unfortunately is required = given > > how > > > > > most software interacts with their TLS stack. > > > > > > > > A few months ago we had a lengthy discussion on the list and at= TRON > > > > about how risky 0-RTT is. This culminated in the idea that 0RTT= data > > > > should be provided through a distinct channel to the applicatio= n, > > > > along with feedback about whether it was not accepted. If we're= > > > > willing to change the interaction pattern to support that, we c= an > > > > accommodate using 0RTT as an extension by gathering it all and = sending > > > > when the handshake happens. But it sounds like you are discussi= ng a > > > > design where the handshake fakes completion if 0-RTT is on, and= at > > > > some point later "well, i didn't actually send the data you wan= ted > > > > to". Or am I missing something about the API design that is mot= ivating > > > > this streaming approach? > > > > > > Sticking 0-RTT data into ClientHello also has the following probl= ems: > > > - One needs to mangle ClientHello (strip an extension on receiver= side) > > > to obtain hash suitable for key derivation for 0-RTT. To do it = any > > > other way either doesn't work, or are cryptographically quite r= isky. > > > - It bloats ClientHello, something you rather not bloat, especial= ly > > > with DTLS. > > > > here's a crazy idea: > > > > - introduce a new extension which has meaning of "more data follow= s" > > - if the server finds it, it expects another Handshake Protocol me= ssage > > from the client > > - the client sends a new "ClientHelloExtension" message that inclu= des > > additional data, in practice it's continuation of the extension = list > > (just let's use 3 byte length fields in the structure) > > > > the obvious downside is, that TLSv1.2 servers do not support it now= > > > > the upsides are: > > * TLSv1.2 servers can be fairly easily updated to support > > it but ignore it (just feed the next message to handshake hash, = but not > > interpret it) - that fixes the upgrade scenario and allows the p= rocess > > to > > be performed in two steps, either of which can then be safely re= versed > > >=20 > We could just as easily update TLS 1.2 servers to know how to skip ea= rly > data. Or, better yet, update those servers to TLS 1.3. you need to update the TLS1.2 server implementation only if you have a = farm, are planning to use 0-rtt and only when you plan TLS 1.3 deployment soon > The problem is requiring those servers to update to begin with. At le= ast > for browsers and the web, any solution that assumes we will get the e= ntire > install-base updated in bounded time won't work. It took us 15 years = to get > rid of SSL 3.0 and even then, with a widely publicized protocol bug a= nd a > cutesy name, it was *still* a hassle and took a lot out of metaphoric= al > breakage budget. but we did, and the same thing will happen with TLS1.0, TLS1.1 and=20 most likely TLS1.2 and at that time this mechanism will be usable for all servers as TLS1.= 3 servers will depend on it =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 --nextPart2318608.QtIYAy4oZL 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 iQIcBAABCgAGBQJXcsFRAAoJEJKo0bgB0vX1mvUP/iM2RAu6yQAN1ch5JsTyWy+K cc8RoIveT6jjM5EBqII4V5cZYR+OoM82rg8EcRXrHPU3Y8Q/8SUM/zc9VYCBWAc7 PeqBqfIsY2xjQOaCmLYW5VNa1+gwR24/JsDK1NsQFEL8U/X/XvrjfRub0q8Z9Rhr 0+GFBDPQo4a0mrrCE+sHDGXRouyFMCS597wfn4S8MUNeI5u7PjFzW19RzPMjnsBE 1WQwW/8YqRGA0ciwgurzQpK6WAz6HmsLYAv6I1DmBhDYhc24qpO7kZk1JJSELr+V orFQqetlYuqMFGJWcegfLBAZgW9b8Z5dlq+yHE+J4+aXO4bntO60+1JmaRVEaxlV dBzzE8RubnmU0znZxv16TNjf1P2P+dqzihjMeoZ/MouFDY74YxMDmfevIYGGEu0I cfY0Lbvo60s1p1CjN6UpkJVa6dGoBdOmTF+TnC2fPVKAWcf0gOR1t/SaR5l+9nas Nq9pMdRyeNsY0IA5Pnxsno6kDoYlO46O+sYbRlgGyUIlHzUfweMruq3htFXbisDx ddmRHFS6u0G97jloDWUzr2HCKxKg+pPTYkDYXAtj/uwGg3bAs/OWIXUFCdVi6diQ z9PLqkP2MRwhDxL6W+eaTi95rW+YiDYu14fklUsQ4TVVF7wGT3oKnrpJaqphjrn9 hprfQakCQqBixqXZwX0D =fJDp -----END PGP SIGNATURE----- --nextPart2318608.QtIYAy4oZL-- From nobody Tue Jun 28 12:47:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FCB12D787 for ; Tue, 28 Jun 2016 12:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApllHvhqyIlz for ; Tue, 28 Jun 2016 12:46:56 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDFC12D750 for ; Tue, 28 Jun 2016 12:46:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 085B47F85; Tue, 28 Jun 2016 22:46:55 +0300 (EEST) 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 5ZJ9MJ-_NIUF; Tue, 28 Jun 2016 22:46:54 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id B1B5128A; Tue, 28 Jun 2016 22:46:54 +0300 (EEST) Date: Tue, 28 Jun 2016 22:46:53 +0300 From: Ilari Liusvaara To: Hubert Kario Message-ID: <20160628194653.GA4268@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160623155339.GA5659@LK-Perkele-V2.elisa-laajakaista.fi> <2279135.STQlCAVDxp@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2279135.STQlCAVDxp@pintsize.usersys.redhat.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Jun 2016 19:46:59 -0000 On Tue, Jun 28, 2016 at 07:01:51PM +0200, Hubert Kario wrote: > On Thursday 23 June 2016 18:53:39 Ilari Liusvaara wrote: > > > > Sticking 0-RTT data into ClientHello also has the following problems: > > - One needs to mangle ClientHello (strip an extension on receiver side) > > to obtain hash suitable for key derivation for 0-RTT. To do it any > > other way either doesn't work, or are cryptographically quite risky. > > - It bloats ClientHello, something you rather not bloat, especially > > with DTLS. > > here's a crazy idea: > > - introduce a new extension which has meaning of "more data follows" > - if the server finds it, it expects another Handshake Protocol message > from the client > - the client sends a new "ClientHelloExtension" message that includes > additional data, in practice it's continuation of the extension list > (just let's use 3 byte length fields in the structure) > > the obvious downside is, that TLSv1.2 servers do not support it now And that is the killer. Remember, what we are discussing is a feature that server has to explicitly enable: Clients aren't going to use it uninvited. TLS 1.2 is going to be around for a long time (unfortunately). Including bad implementations with serious issues. -Ilari From nobody Wed Jun 29 10:00:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357E012D1CA for ; Wed, 29 Jun 2016 10:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QGGzvAeU-0X for ; Wed, 29 Jun 2016 10:00:32 -0700 (PDT) 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 BE73812D0D3 for ; Wed, 29 Jun 2016 10:00:32 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id f30so51476412ioj.2 for ; Wed, 29 Jun 2016 10:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=I0NCmPAZuWvA/T3/ez0yfhcV9m5BMRtibkMNV/28nZg=; b=djTzHTH9Xi6J8rSDwhLySjNh3NlLjxvX8ErzBgrBLVqH43RZmw5ElawWukcV8ByXSM srocij1D1O/jzUPvcfhsKSeQPwNDuj+tJmiuyPcQeuZRbkHYwcSNh/Pyo1KbFNc1xB0M QCqdF8XqM0lo+WnzyXSaCesBnsXJJbTwXeMXup+pqrTe15KtfJuWpygdMCeGAoEWjyVv ITa3AoC5Epw42UW/HYi83sPaLc/6K7kn/6m1dDN+4Kh9lX0espaiIvJ9Ki1/S4+ACpHt J9mQBQTNc/ovVHM6Nt+QptAwO3AE7KN6EB0OsbHHCng2ndPHZX0nHYxdG4AKVu4XqYy1 qmAg== 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:cc; bh=I0NCmPAZuWvA/T3/ez0yfhcV9m5BMRtibkMNV/28nZg=; b=NY1OKMd7N27/YEpc6gzlwpDmho/J0xcNP9QbOn7vB3pmVs33sPV3rm4wp5qC4gMy96 zcIBRcXSHWHxwfVOJ17PeJtQ47gxNq3B1DIqwtGLw1k6p8rfrjtLyhy/cOtRmHDGSBBg s6dDvv1rhU225QV7eus87Ko8Y/bICrk0R239B6Kk55CdDWHeXtQzf/2zIsxVG0sLwGoJ oJJOepDCaplod4kzysSlu4x3P0nZoPcqGrp0dz2iz/TnLD2in7etPBLUysPnwanXyiW1 Woy5pdaqx8bhPCAs6CmddxECfX8xYD+cz/+1aQUBEp4cwTsA34N/J+/pG05WXggVsOMZ xHTQ== X-Gm-Message-State: ALyK8tL1Mszj2Dqp9y0EhzC3JzznCmzLKVPtIf9OAgFPS4csPlKEYu2BWzl1lyYex+uLOIHUzsrLFd94i4AxkQ== X-Received: by 10.107.34.5 with SMTP id i5mr11967136ioi.8.1467219632025; Wed, 29 Jun 2016 10:00:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.115.36 with HTTP; Wed, 29 Jun 2016 10:00:17 -0700 (PDT) From: Dmitry Khovratovich Date: Wed, 29 Jun 2016 19:00:17 +0200 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a1140ea50f9752f05366db09a Archived-At: Cc: Alex Biryukov - UNI , "Nygren, Erik" Subject: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2016 17:00:37 -0000 --001a1140ea50f9752f05366db09a Content-Type: text/plain; charset=UTF-8 Dear all, together with our colleagues from Akamai, we would like to pursue further the draft on the TLS client puzzles, the first version of which was aired in 2015. As before, the client puzzles allow a server to request clients perform a selected amount of computation prior to the server performing expensive cryptographic operations such as signature computation. The distinction of the current version is that it includes, besides the well-known SHA-2 puzzle, a memory-hard puzzle called Equihash. The latter is a recent development by our team in Luxembourg, presented at this year NDSS. It allows cheap and memoryless verification by the server even though the puzzle solving guaranteely requires dozens of MB of RAM from a client (time, memory, and client-server asymmetry are tunable parameters). Equihash has been recently adopted as primary proof-of-work in the privacy-enhanced cryptocurrency protocol Zcash. The draft is available at https://datatracker.ietf.org/doc/draft-nygren-tls-client-puzzles/ and the Equihash paper at https://www.internetsociety.org/sites/default/files/blogs-media/equihash-asymmetric-proof-of-work-based-generalized-birthday-problem.pdf We would appreciate comments and discussion, and would like to present the draft at the upcoming IETF meeting in Berlin. -- Best regards, Dmitry Khovratovich University of Luxembourg --001a1140ea50f9752f05366db09a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

together with our colleagues = from Akamai, we would like to pursue further the draft on the TLS client pu= zzles, the first version of which was aired in 2015. As before, the client = puzzles allow a server to request clients perform a selected amount of comp= utation prior to the server performing expensive cryptographic operations s= uch as signature computation.=C2=A0

The distinctio= n of the current version is that it includes, besides the well-known SHA-2 = puzzle, a memory-hard puzzle called Equihash. The latter is a recent develo= pment by our team in Luxembourg, presented at this year NDSS. It allows che= ap and memoryless verification by the server even though the puzzle solving= guaranteely requires dozens of MB of RAM from a client (time, memory, and = client-server asymmetry are tunable parameters). Equihash has been recently= adopted as primary proof-of-work in the privacy-enhanced cryptocurrency pr= otocol Zcash.

The draft is available at=C2=A0ht= tps://datatracker.ietf.org/doc/draft-nygren-tls-client-puzzles/=C2=A0

We would appreciate = comments and discussion, and would like to present the draft at the upcomin= g IETF meeting in Berlin.


--
Best regards,
Dmitry Khovratovich
University of Luxembourg
--001a1140ea50f9752f05366db09a-- From nobody Wed Jun 29 12:25:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A3312D563 for ; Wed, 29 Jun 2016 12:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmmgeVEprxPV for ; Wed, 29 Jun 2016 12:25:45 -0700 (PDT) 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 3B5DB12D558 for ; Wed, 29 Jun 2016 12:25:45 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id s63so54978114ioi.3 for ; Wed, 29 Jun 2016 12:25:45 -0700 (PDT) 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:from:date:message-id:subject:to :cc; bh=UWOCZbRmS4uhcdOCLKbY51hHEyhkAeFbRqZ707hORZ8=; b=J5NnRsaWQuCoIayVOExhTySRMjRaVFLqrc4P65x/y+LR8WxQyD6GDp7y6cxOhoY/Ae ukK4IlVnwY3Q8+E/mc03sqs9oAH+hirwPU90O9gYL7wo8h/M38QjrpV1LXFVgXlwgp6b T6ph8tm3VX5Qikp6nliPU5iMpQL4PVz3kG5DRZr+CZhPf7+1wMlBiCc7lx4xzro7KptB FTWo7WYWv8sgmuaYsUGtkm8VyOCGrx8Uf9bckt7yI0hYDSX3Y+pf1nCTzVmDHZFiOM1i /uhjA0dwZctjxCg8+AZBlcnBUZf+3oul9gtOUd8P0rYqc0JcYtSWmxnvCRAgKRpeetqZ uy0g== 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; bh=UWOCZbRmS4uhcdOCLKbY51hHEyhkAeFbRqZ707hORZ8=; b=i6dc5b6PQiTSLgLnaqI5DuusLnPjFa7IDC9Nc+ld7ERObi9vBp3l/Ju1Jk9JlwSxO0 7DKB/Ums04pUT9nFKki5mFd8MDful5O7K0rUvU4dtUZlRlmM8HUx05uipV9B4/AhWC8d /CkA2M0VwRYbo1CdV4qFHpY6dHTdrxgmqi41h4Jbcof1W0K3vQh2mOogKrnp7SHOdCKM UnzQznbBIdo+aEsYd6Xs5O1DuVSgkkftDkoXfQQv9hNmdPf2b/V26lTaDwHz58wq53II fppQcaEo3YL5S1epfsuR3f6Ox8O664hbKbFRcOf4Pl7jGHdcb1lBfwVXseS20V0AXehI HS0Q== X-Gm-Message-State: ALyK8tKFrTuDvicYcKq9KoN13k2UGyP59+AFCxLjnbk1CRrvhxIOf9LQbIigcKau5j9aJhmDDp6s5taGYe5Eag== X-Received: by 10.107.9.169 with SMTP id 41mr11147340ioj.196.1467228344472; Wed, 29 Jun 2016 12:25:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.73.134 with HTTP; Wed, 29 Jun 2016 12:25:44 -0700 (PDT) In-Reply-To: References: From: Brian Smith Date: Wed, 29 Jun 2016 09:25:44 -1000 Message-ID: To: Dmitry Khovratovich Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2016 19:25:47 -0000 Dmitry Khovratovich wrote: > It allows cheap and memoryless verification by the server even though the > puzzle solving guaranteely requires dozens of MB of RAM from a client I feel like this is impractical simply because lots of people are building HTTPS clients that don't even have dozens of MB of RAM total. I think we should avoid doing anything that requires the client to have more than ~16KB of memory total to devote to TLS stuff. Otherwise, we force the internet to have an architecture where all small devices require a smart proxy to solve these puzzles for them and do other things. Cheers, Brian -- https://briansmith.org/ From nobody Wed Jun 29 13:51:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213C412D7A1 for ; Wed, 29 Jun 2016 13:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBHrfz6GR8ch for ; Wed, 29 Jun 2016 13:51:16 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 E2CFD12D7AF for ; Wed, 29 Jun 2016 13:51:14 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id h190so53611087ith.1 for ; Wed, 29 Jun 2016 13:51:14 -0700 (PDT) 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 :cc; bh=b8mPak+CVKYhrds9hSJxtLufE6d7GZJvtwZIwEZz8QI=; b=YPE6+nz0sDB6rc8UmKheZkMycmbc1JAnnMuXYc8P4M4F1rpFqvV0kGrRmWAc66PBB8 p3+ss30GGaF9DkJ4CmaDT9FL/bahPm4hpj5KhvVCL4abty12F651/0kOgZbrPRQfUQT9 yyO8Rz7vkblXPQpozmRKaWCSlgTx3wRkuVK0w= 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:cc; bh=b8mPak+CVKYhrds9hSJxtLufE6d7GZJvtwZIwEZz8QI=; b=FayywxLLSeyGKmDIpOQr99cvViTp8fqomFYA86BfHULJKe7yl8uzZKp6wNK7IShFsc MQMHSPWqEz5bd9JvNGySHhksqGMu/WgDG2oTLMyH7evKYspWLJ5OLj2WyKI8cAIEXa2D H7Evo7CbZFVjpyxKp4+tN3Gn2vOvwffLItFdVo34LvK1dTiBPQMxLmY+d/bT/SgK0EDr 4JH7qU0q7SwMgwPGGgU3bTI+uK28l3NQVr6h6oarCz0zu7ZUHYd5MGLz0IHtaMrYujl+ W8oBgNvbRq1qXgY12eAExWHRO9CkX1in54akxnqUlSqPduimGVQRhj1RGMr18ncmEwEW QYvA== X-Gm-Message-State: ALyK8tLbuOoHvH/7lUx3MDLJt1VS8Vd8dtNRIG4VK3vFwGXLUgBkupLIibpgW06pvjE3G6DU7BPRB2GBwOIi6wC7 X-Received: by 10.36.101.74 with SMTP id u71mr12041453itb.92.1467233474069; Wed, 29 Jun 2016 13:51:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 29 Jun 2016 20:51:04 +0000 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1145bcf206c08d053670ea2b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Downgrade protection, fallbacks, and server time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2016 20:51:19 -0000 --001a1145bcf206c08d053670ea2b Content-Type: text/plain; charset=UTF-8 On Wed, Jun 1, 2016 at 6:57 PM Eric Rescorla wrote: > On Wed, Jun 1, 2016 at 3:53 PM, David Benjamin > wrote: > >> On Wed, Jun 1, 2016 at 6:43 PM Eric Rescorla wrote: >> >>> 2% is actually pretty good, but I agree that we're going to need >>> fallback. >>> >>> I'd be fine with moving the 8 bytes to the end, but I wonder if it would >>> be better to >>> instead have the *client* indicate its max version and the server check. >>> That would >>> have the advantage that it would leave more of the server random intact. >>> >> >> That sounds reasonable to me. I'd probably suggest still putting it at >> the end since there's no reason to risk things, but I'm not aware of >> anything that uses the client timestamp. (None of the clients I maintain >> send it.) >> > > Putting it at the end of the client gives the client options, so that > would be fine. > To get this thread back on the original point, I put together a PR here for the minimal change which just moves it to the end of server_random. This would be sufficient to fix the problem which prevents today's 1.2 servers from implementing 1.3. https://github.com/tlswg/tls13-spec/pull/508 I don't particular care whether it's moved to the client or not. If you think that's better, I'm happy to change it or defer to a different PR. (I wasn't sure exactly what construction you were thinking for the client_random version.) David > > >> >>> -Ekr >>> >>> P.S. The FALLBACK_SCSV isn't a substitute because it isn't signed by the >>> server. >>> >> >> Yeah, FALLBACK_SCSV only gives us TLS 1.0-1.2-level downgrade protection >> (otherwise the version fallback even loses that one). I only mean in terms >> of mitigating the additional damage done by the fallback, not replacing the >> entire mechanism. >> >> (Although, do we actually get the stronger protection if the client >> accepts plain RSA key exchange? I've never been very clear on that. >> Realistically, clients will be accepting plain RSA for a long while.) >> > > Yes, that's correct. I don't believe we have a good plan for plain RSA. > > -Ekr > > >> David >> >> >>> >>> On Wed, Jun 1, 2016 at 3:29 PM, David Benjamin >>> wrote: >>> >>>> In case folks hoped we could bump the ClientHello version without those >>>> dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much >>>> exists. (Maybe we should just give up on ClientHello.version and use an >>>> extension? Extensions have rusted less.) >>>> >>>> I picked a large list of top sites and tried connecting to them. Just >>>> under 2% of them could handle a TLS 1.2 ClientHello, but not the same >>>> ClientHello with the version switched to 1.3 (no other changes, so I >>>> haven't tested a real 1.3 ClientHello). They're not unknown hosts either. I >>>> expect if you probe any top site list, you'll very quickly find some. >>>> >>>> Fortunately, the ServerHello.random trick fixes this. But it currently >>>> clobbers the old server timestamp which tlsdate[1] uses for clock >>>> synchronization. There really should be a less silly secure timestamping >>>> protocol, but, today, tlsdate has users. Any servers which expect to be a >>>> tlsdate target can't honor this MUST without tlsdate gone. >>>> >>>> (FALLBACK_SCSV works fine as well, but I gather people prefer the >>>> ServerHello.random one and would be unhappy having to implement both in >>>> clients with a fallback because not all servers do the latter.) >>>> >>>> I mentioned this before, but rather than clobbering the first 8 bytes, >>>> the last 8 bytes seems as reasonable and avoids this unnecessary >>>> complication to TLS 1.3 deployment. If folks agree now that the >>>> fallback's resurrection is more certain, I'm happy to put together a PR. >>>> >>>> David >>>> >>>> [1] https://github.com/ioerror/tlsdate >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>>> >>> --001a1145bcf206c08d053670ea2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 1,= 2016 at 6:57 PM Eric Rescorla <ekr@rtfm= .com> wrote:
On Wed, Jun 1, 2016= at 3:53 PM, David Benjamin <davidben@chromium.org> wrot= e:
On Wed, Jun 1, 2016 at 6:43 PM Eric Rescorla &= lt;ekr@rtfm.com> w= rote:
2% is actual= ly pretty good, but I agree that we're going to need fallback.

=
I'd be fine with moving the 8 bytes to the end, but I wonder= if it would be better to
instead have the *client* indicate its = max version and the server check. That would
have the advantage t= hat it would leave more of the server random intact.

That sounds reasonable to me. I'd probably= suggest still putting it at the end since there's no reason to risk th= ings, but I'm not aware of anything that uses the client timestamp. (No= ne of the clients I maintain send it.)
<= br>
Putting it at the end of the client gives the c= lient options, so that would be fine.
<= div>
To get this thread back on the original point, I put tog= ether a PR here for the minimal change which just moves it to the end of se= rver_random. This would be sufficient to fix the problem which prevents tod= ay's 1.2 servers from implementing 1.3.


I don't particula= r care whether it's moved to the client or not. If you think that's= better, I'm happy to change it or defer to a different PR. (I wasn'= ;t sure exactly what construction you were thinking for the client_random v= ersion.)

David
=C2=A0

=C2=A0
-Ekr

P.S. The FA= LLBACK_SCSV isn't a substitute because it isn't signed by the serve= r.

=
Yeah, FALLBACK_SCSV only = gives us TLS 1.0-1.2-level downgrade protection (otherwise the version fall= back even loses that one). I only mean in terms of mitigating the additiona= l damage done by the fallback, not replacing the entire mechanism.

(Although, do we actually get the stronger protection if the client a= ccepts plain RSA key exchange? I've never been very clear on that. Real= istically, clients will be accepting plain RSA for a long while.)

Yes, that's corr= ect. I don't believe we have a good plan for plain RSA.

<= /div>
-Ekr


David
=C2=A0

On Wed, Jun 1, 2016 at 3:29 PM, David= Benjamin <davidben@chromium.org> wrote:
=
In = case folks hoped we could bump the ClientHello version without those dreade= d browser fallbacks, I have bad news. :-( 1.3 intolerance very much exists.= (Maybe we should just give up on ClientHello.version and use an extension?= Extensions have rusted less.)

I picked a large list of = top sites and tried connecting to them. Just under 2% of them could handle = a TLS 1.2 ClientHello, but not the same ClientHello with the version switch= ed to 1.3 (no other changes, so I haven't tested a real 1.3 ClientHello= ). They're not unknown hosts either. I expect if you probe any top site= list, you'll very quickly find some.

Fortunat= ely, the ServerHello.random trick fixes this. But it currently clobbers the= old server timestamp which tlsdate[1] uses for clock synchronization. Ther= e really should be a less silly secure timestamping protocol, but, today, t= lsdate has users. Any servers which expect to be a tlsdate target can't= honor this MUST without tlsdate gone.

(FALLBACK_S= CSV works fine as well, but I gather people prefer the ServerHello.random o= ne and would be unhappy having to implement both in clients with a fallback= because not all servers do the latter.)

I mention= ed this before, but rather than clobbering the first 8 bytes, the last 8 by= tes seems as reasonable and avoids this unnecessary complication to TLS 1.3= deployment.=C2=A0If folks agree now that t= he fallback's resurrection is more certain, I'm happy to put togeth= er a PR.

David


<= div class=3D"gmail_extra">
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--001a1145bcf206c08d053670ea2b-- From nobody Wed Jun 29 14:08:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7797212D7F9 for ; Wed, 29 Jun 2016 14:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIu8aFErcgOi for ; Wed, 29 Jun 2016 14:08:24 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 8E0CB12D7E7 for ; Wed, 29 Jun 2016 14:08:23 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id w59so32470031qtd.3 for ; Wed, 29 Jun 2016 14:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EAEQHoI2aKIUiEEClF0gDJkrpt7Nhv4l3szJnMzXg08=; b=UUiALkVTnAfuwihpbtMGSPrZCV/XFIwHbKTxnOMgC5t/iXUETO06loKUUPLCr5wncZ N39WHbjCW5S4g3HOdtrTZO1vzVufXHRxVljLXttFlN8fKVidjSZTzvKfqNkSmFy2d628 QSs4lrG5d3QPrhUiyTFCTvqsBrw+ZlvpS9pbE= 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; bh=EAEQHoI2aKIUiEEClF0gDJkrpt7Nhv4l3szJnMzXg08=; b=hLUeWnk1L2WnevP/5+MCsoe8UzaZl1ea5kVX/paNqTpttPeHkhvJNsEbHe1Nm2h8MT iYv5yXqjGhQCYuZ9LEl6BUtb1fmSwDW0oH9m7g69wK7j/vrSsDkZsB2TAuiPfjsnu1LW Kvo5awC5cuYkLLJaQjtc+YkN/7ipvsvYZN2iq1mhvvecJtShKGzGX5pjFp/EQaSPtRlZ 969drqNq7WyEdqVnrZ7uZgojdrom9592du/sppvOJsbDSFRzIpVc4U12wps5Un/F4RiB XwcS3iNw2wc8lR0naJV7A7RLcbB1cLpZbgNxnz4R0LocOlvFTBNlRCwFlTwYHzNNQGt/ d1yg== X-Gm-Message-State: ALyK8tJOYr3DyXkweoQPIAqHlGj5pl4TMAI/gyNA85qmX3CeacBL9KywHVeUJXGrMktg7HOsn0dm9NqUufZ85g== X-Received: by 10.200.41.163 with SMTP id 32mr17501644qts.101.1467234502706; Wed, 29 Jun 2016 14:08:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.80.66 with HTTP; Wed, 29 Jun 2016 14:08:22 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: References: From: Kyle Rose Date: Wed, 29 Jun 2016 17:08:22 -0400 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=001a1135763856305d0536712721 Archived-At: Cc: Dmitry Khovratovich , "" Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2016 21:08:27 -0000 --001a1135763856305d0536712721 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 29, 2016 at 3:25 PM, Brian Smith wrote: > Dmitry Khovratovich wrote: > > It allows cheap and memoryless verification by the server even though the > > puzzle solving guaranteely requires dozens of MB of RAM from a client > > I feel like this is impractical simply because lots of people are > building HTTPS clients that don't even have dozens of MB of RAM total. > I think we should avoid doing anything that requires the client to > have more than ~16KB of memory total to devote to TLS stuff. > Otherwise, we force the internet to have an architecture where all > small devices require a smart proxy to solve these puzzles for them > and do other things. > I think the appropriateness of client puzzles depends on what sorts of tradeoffs we're willing to accept. Let's say we have a DoS attacker profile that is not distinguishable from legitimate traffic, since that's the hard case. Do we want to be able to serve *some* traffic during a DoS attack? If we can't distinguish between legitimate users and attack traffic, we have to assume everyone's a potential attacker. It seems what we're left with is either rationing client requests or raising the cost of requests. Rationing can be sliced up in any number of ways, but effectively amounts to randomly denying some percentage of legitimate requests because we're assuming attack traffic and legitimate traffic have the same profile. (In reality, outside of NAT scenarios, we may be able to give immediate service to existing clients and ration new clients; but we're assuming the horse is a sphere for the sake of argument.) Raising the cost of requests has a similar problem in that you're punishing every client, but in doing so you do allow all clients capable of absorbing the increased cost (e.g., memory, computing power) to get access to the resources they need if the user is willing to accept that cost (e.g., energy, latency). The problem you pointed out is that of clients that aren't capable of absorbing the increased cost, such as low-power or memory-constrained embedded devices. This is a legitimate concern, but I don't think it universally disqualifies client puzzles. Maybe memory-hard puzzles aren't appropriate for services that talk to IoT devices, but that doesn't mean they aren't appropriate for websites that serve primarily to browsers. To benefit from client puzzles on their websites, providers running IoT REST services on the same server running their website may want to reconsider that arrangement. Any client puzzle proposal must of course allow the server to choose whether and when to issue a client puzzle, which in the absence of authenticated client identity information should probably be based on the expected client profile. Tl;dr: memory-hard client puzzles are not universally appropriate as a DoS defense, but I don't think that means they are never appropriate. Kyle --001a1135763856305d0536712721 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 29, 2016 at 3:25 PM, Brian Smith <brian@briansmith.org><= /span> wrote:
Dmitry Kho= vratovich <khovratovich@gmail.= com> wrote:
> It allows cheap and memoryless verification by the server even though = the
> puzzle solving guaranteely requires dozens of MB of RAM from a client<= br>
I feel like this is impractical simply because lots of people are building HTTPS clients that don't even have dozens of MB of RAM total.<= br> I think we should avoid doing anything that requires the client to
have more than ~16KB of memory total to devote to TLS stuff.
Otherwise, we force the internet to have an architecture where all
small devices require a smart proxy to solve these puzzles for them
and do other things.

I think the approp= riateness of client puzzles depends on what sorts of tradeoffs we're wi= lling to accept. Let's say we have a DoS attacker profile that is not d= istinguishable from legitimate traffic, since that's the hard case. Do = we want to be able to serve *some* traffic during a DoS attack? If we can&#= 39;t distinguish between legitimate users and attack traffic, we have to as= sume everyone's a potential attacker. It seems what we're left with= is either rationing client requests or raising the cost of requests.
Rationing can be sliced up in any number of ways, but effectiv= ely amounts to randomly denying some percentage of legitimate requests beca= use we're assuming attack traffic and legitimate traffic have the same = profile. (In reality, outside of NAT scenarios, we may be able to give imme= diate service to existing clients and ration new clients; but we're ass= uming the horse is a sphere for the sake of argument.)

Raising the c= ost of requests has a similar problem in that you're punishing every cl= ient, but in doing so you do allow all clients capable of absorbing the inc= reased cost (e.g., memory, computing power) to get access to the resources = they need if the user is willing to accept that cost (e.g., energy, latency= ).

The problem you pointed out is that of clients that ar= en't capable of absorbing the increased cost, such as low-power or memo= ry-constrained embedded devices. This is a legitimate concern, but I don= 9;t think it universally disqualifies client puzzles. Maybe memory-hard puz= zles aren't appropriate for services that talk to IoT devices, but that= doesn't mean they aren't appropriate for websites that serve prima= rily to browsers. To benefit from client puzzles on their websites, provide= rs running IoT REST services on the same server running their website may w= ant to reconsider that arrangement. Any client puzzle proposal must of cour= se allow the server to choose whether and when to issue a client puzzle, wh= ich in the absence of authenticated client identity information should prob= ably be based on the expected client profile.

Tl;dr: memo= ry-hard client puzzles are not universally appropriate as a DoS defense, bu= t I don't think that means they are never appropriate.
Kyle

--001a1135763856305d0536712721-- From nobody Wed Jun 29 14:41:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530CF12B056 for ; Wed, 29 Jun 2016 14:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWRHLtM8pr9D for ; Wed, 29 Jun 2016 14:41:12 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0139.outbound.protection.outlook.com [207.46.100.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 9170C12B04F for ; Wed, 29 Jun 2016 14:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Z6t4i+/AevsNRCJv2AWJrUkVQT/hHKPOv3BvUVP5+bo=; b=ZRiCfp7lIkYSCMSEhJZrNiEztHR4WkC7IzlAsPBeO4mTS0PKFWcjeoMPvH1SLXWdr5rZCoJsSOd2Vz6qqbrbXH6zBMgRzivg349uUrCOFb2pliUNYcyQJwnVJrCAs1u3NWEmPRhFUGosnlXY8TdSr3zrIfCcDvtHt5F1wC2nJEU= 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 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.523.12; Wed, 29 Jun 2016 21:41:10 +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.0523.024; Wed, 29 Jun 2016 21:41:10 +0000 From: Christian Huitema To: Kyle Rose , Brian Smith Thread-Topic: [TLS] TLS client puzzles Thread-Index: AQHR0ifMJX0hxBbnB0iEPkhnsCR1RaAA078AgAAcrQCAAAXvUA== Date: Wed, 29 Jun 2016 21:41:10 +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:3::110] x-ms-office365-filtering-correlation-id: 5e1f01fd-066a-4171-d5e1-08d3a066162e x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0655; 6:3UlF87M3owN/ywDT08dm10jsqhLgNbXm2uDRtss7X0bpHZKsmFB3arVIfaHCjmpDq50txIeDAaCh9dFq3A1Ua8fNDhuxXt6eHU9cYf14JNdLtUYsIaZvCZSoqczFN0GTZ1Ui8Uv9WbAxHZqDgyxmIFfzBm8PWU4xNDzQvnze1mC0+6Q1ljTRoT7F+0cg8D+4XwIsGNM6WxbXxeWzNeJwmwlQI3KcGyHaEpTx8kCXkXfspxA/OmAxYhXX3vyCeAKn3PFbPSwmim41Xu9qaiibIy2qHRK69Dgh+rvNsoLtuxpuP8l+q+i6ZJyGeIXH+OFIBQqKH/LU3b1K+HcbCVg3lozTNgl4GxWMswEYRTNZfBo=; 5:IuZ/5Oe+KXJO6ZoYu48zE854aLNFEWPMBMlygYN3p87DAWh0ynO2Va3JHiQm7QoITlTu3w9nEOxZEGQfAYDEbzHD3UckB5RFwZUkaOlR8FyEZ0D+M8UXW/WuVUSMkocU/pYTsXBxhZ0qQi5o11++fQ==; 24:ruoaV9Xt+YweMQqh63azFfuEYMuox3PFhSnfuMMih3DybW0gIV2KQS0R/9U0mnw21SCZVPI7mHc2QExOEqnv9S3b/zYcVqtkt98Ols71orE=; 7:FH33HtFkS1Gda1a3e/6uJNnFEM8mi4rHLZmyTQJIcUSAT8vcgboEm/6+J5+Rjp0obvqTW+jpat4Xj5WvWJ+25iMYe4EFmG8RVURZmCh+0FRfW5KwArc/ibtXV+WklwNSrx2bDQKwJfoYyrr7UTjVPo1uaBPXn76nEqCnPoPOh2yi8TiPMCFgb0Tk9J3XKxt3J9ZSMpPkVmRAROXr5KtBgM8/fxknEwEpG9d2oZfdyFmDpREnXx2/1sp078g7OEkpk6p5BghdoZP4IxtN47fKR16gepESc3wXzUgOVCOMcoc= 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)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0655; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655; x-forefront-prvs: 09888BC01D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(189002)(24454002)(199003)(5003600100003)(86362001)(7696003)(8936002)(2906002)(2950100001)(6116002)(102836003)(2900100001)(7736002)(586003)(122556002)(106356001)(3280700002)(10400500002)(8990500004)(305945005)(5002640100001)(101416001)(11100500001)(5005710100001)(10290500002)(3660700001)(87936001)(7846002)(105586002)(50986999)(8676002)(97736004)(77096005)(9686002)(99286002)(106116001)(4326007)(74316001)(33656002)(189998001)(5001770100001)(86612001)(54356999)(68736007)(81166006)(76576001)(81156014)(76176999)(10090500001)(92566002)(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:99 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 Jun 2016 21:41:10.7187 (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: Dmitry Khovratovich , "" Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2016 21:41:14 -0000 T24gV2VkbmVzZGF5LCBKdW5lIDI5LCAyMDE2IDI6MDggUE0sIEt5bGUgUm9zZSB3cm90ZToNCj4N Cj4gUmFpc2luZyB0aGUgY29zdCBvZiByZXF1ZXN0cyBoYXMgYSBzaW1pbGFyIHByb2JsZW0gaW4g dGhhdCB5b3UncmUgcHVuaXNoaW5nIA0KPiBldmVyeSBjbGllbnQsIGJ1dCBpbiBkb2luZyBzbyB5 b3UgZG8gYWxsb3cgYWxsIGNsaWVudHMgY2FwYWJsZSBvZiBhYnNvcmJpbmcgDQo+IHRoZSBpbmNy ZWFzZWQgY29zdCAoZS5nLiwgbWVtb3J5LCBjb21wdXRpbmcgcG93ZXIpIHRvIGdldCBhY2Nlc3Mg dG8gdGhlIA0KPiByZXNvdXJjZXMgdGhleSBuZWVkIGlmIHRoZSB1c2VyIGlzIHdpbGxpbmcgdG8g YWNjZXB0IHRoYXQgY29zdCAoZS5nLiwgZW5lcmd5LCANCj4gbGF0ZW5jeSkuDQoNClRoZSBvYnZp b3VzIGlzc3VlIHdpdGggdGhlICJwcm9vZiBvZiB3b3JrIiBkZWZlbnNlIGFnYWluc3QgRERPUyBp cyB0aGF0IHRoZSBib3QgbmV0cyBjYW4gZG8gbW9yZSB3b3JrIHRoYW4gbWFueSBsZWdpdGltYXRl IGNsaWVudHMuIFRoZSBwdXp6bGUgYXBwcm9hY2ggd2lsbCBjdXQgb2ZmIHRoZSBsZWFzdCBjYXBh YmxlIGxlZ2l0aW1hdGUgY2xpZW50cywgc3VjaCBhcyBvbGQgcGhvbmVzIG9yIElPVCBkZXZpY2Vz LiBJdCB3aWxsIG5vdCBjdXQgb2ZmIHRoZSBQQyBlbnJvbGxlZCBpbiBhIGJvdCBuZXQuIEl0IHdp bGwgbWVyZWx5IHNsb3cgaXQgZG93biBhIGxpdHRsZS4gQnV0IHRoZW4sIHlvdSBjb3VsZCBoYXZl IHRoZSBzYW1lIGVmZmVjdCBieSBqdXN0IGRlbGF5aW5nIHRoZSByZXNwb25zZSBhbmQgZW5mb3Jj aW5nIG9uZSBjb25uZWN0aW9uIHBlciBjbGllbnQuDQoNCi0tIENocmlzdGlhbiBIdWl0ZW1hDQoN Cg0KDQoNCg== From nobody Wed Jun 29 19:00:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EE112D5D8 for ; Wed, 29 Jun 2016 19:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp80ZWa8q7hi for ; Wed, 29 Jun 2016 19:00:10 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 8B79512D593 for ; Wed, 29 Jun 2016 19:00:10 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id m2so35364379qtd.1 for ; Wed, 29 Jun 2016 19:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9HeOh/bwtHMWNkSaD6GDPe6QkUEt3SvOl04P+wGnwc0=; b=lDNGUoS8qGXhWQKO491wE9d1TXIzMw2fubnrlblFEzsfOYD/0FkT7KI3F2j/CokrjG hEk/FjoZaGdIMywPmeatBXVLSxi0g8qdEutpE2aK6cyJlzZHF9mzHKmKOry6ZImd4GvM X6A3vZxX6k8M6YaySIYh6bayrAbxRFc+Ra/Ek= 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; bh=9HeOh/bwtHMWNkSaD6GDPe6QkUEt3SvOl04P+wGnwc0=; b=dojL0ZkDTgGZChXER3lV9mhf7km8V4EeenEaBD44069bxrWdOYqsk5nxUGnPDHBgmC XwwUtdk2tLFcf5vsl95UP5/ezKu44vk1w35r4fYjj/4JxzpzUtY2qSK9L63wreB/8CMF 3TVht+lEmN2nRriktN5Y03XCwK0TZNLhuZuKqnbRzuPMTdcHIWZbD5/74BDcDMVkwScS NVqTXJKuXJNJuqYR7ryqA61x1ezLg12v5ZRfayeFRQvIkxmUW8dmMuHJgW77C4AU7TJS afPWJ/WKC2h6jgF4SMkpg7uIDPT+/nldbvUmwTlQ+dSC8vY8xRjGedcrjHvx4Rzq3IAz /MXQ== X-Gm-Message-State: ALyK8tJc5c2QIRRL+cqORE/UpU/nfHFbUBo8IrLNuEv5sw2T82q2HmENZl1QzxEmU8gkP7Gy+bttqZZhr8XZ6A== X-Received: by 10.200.46.25 with SMTP id r25mr19729016qta.3.1467252009679; Wed, 29 Jun 2016 19:00:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.80.66 with HTTP; Wed, 29 Jun 2016 19:00:08 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:7d87:9ebb:e00f:906b] In-Reply-To: References: From: Kyle Rose Date: Wed, 29 Jun 2016 22:00:08 -0400 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=001a1147ea5ed55b180536753a35 Archived-At: Cc: "" , Dmitry Khovratovich Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2016 02:00:13 -0000 --001a1147ea5ed55b180536753a35 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 29, 2016 at 5:41 PM, Christian Huitema wrote: > On Wednesday, June 29, 2016 2:08 PM, Kyle Rose wrote: > > > > Raising the cost of requests has a similar problem in that you're > punishing > > every client, but in doing so you do allow all clients capable of > absorbing > > the increased cost (e.g., memory, computing power) to get access to the > > resources they need if the user is willing to accept that cost (e.g., > energy, > > latency). > > The obvious issue with the "proof of work" defense against DDOS is that > the bot nets can do more work than many legitimate clients. The puzzle > approach will cut off the least capable legitimate clients, such as old > phones or IOT devices. It will not cut off the PC enrolled in a bot net. It > will merely slow it down a little. But then, you could have the same effect > by just delaying the response and enforcing one connection per client. > I agree with you that the above seems equivalent in theory, but in practice it might not be feasible. The biggest obstacle seems to be enforcing one connection per client. Let's say rate limiting on a per-client basis doesn't work because many of your clients are behind a NAT; or because the attacker is using IPv6 and generates a ton of temporary addresses that make the situation indistinguishable from many legitimate clients in the same subnet. So you can either serve one (or a small N) of them at a time, or you drop that restriction and allow a single client to mount an asymmetric attack. Alternatively, what if you have lots of geographically-distributed servers and can't share client rate limiting state among them quickly enough to detect and blacklist attackers? It's possible there are additional asymmetric attack vectors I'm not thinking of, which is why I like this as a general defense against a class of attacks. I mostly agree it's mostly worthless when you have one server facing a botnet of 100,000 machines, but frankly that one server is a sitting duck regardless of countermeasures. OTOH, what if you have 20,000 servers facing such a botnet? Client puzzles effectively become a mechanism for enforcing distributed rate limiting, and could be used to dramatically raise the cost of mounting such an attack. I have to think a lot more about the IoT/resource-constrained client problem, but I still don't think the existence of clients that would be by this scheme Kyle --001a1147ea5ed55b180536753a35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 29, 2016 at 5:41 PM, Christian Huitema <huitema@microsoft.com<= /a>> wrote:
= On Wednesday, June 29, 2016 2:08 PM, Kyle Rose wrote:
>
> Raising the cost of requests has a similar problem in that you're = punishing
> every client, but in doing so you do allow all clients capable of abso= rbing
> the increased cost (e.g., memory, computing power) to get access to th= e
> resources they need if the user is willing to accept that cost (e.g., = energy,
> latency).

The obvious issue with the "proof of work" defense against= DDOS is that the bot nets can do more work than many legitimate clients. T= he puzzle approach will cut off the least capable legitimate clients, such = as old phones or IOT devices. It will not cut off the PC enrolled in a bot = net. It will merely slow it down a little. But then, you could have the sam= e effect by just delaying the response and enforcing one connection per cli= ent.

I agree with you that the above seems eq= uivalent in theory, but in practice it might not be feasible.

=
The biggest obstacle seems to be enforcing one connection per client. = Let's say rate limiting on a per-client basis doesn't work because = many of your clients are behind a NAT; or because the attacker is using IPv= 6 and generates a ton of temporary addresses that make the situation indist= inguishable from many legitimate clients in the same subnet. So you can eit= her serve one (or a small N) of them at a time, or you drop that restrictio= n and allow a single client to mount an asymmetric attack.

Alternati= vely, what if you have lots of geographically-distributed servers and can&#= 39;t share client rate limiting state among them quickly enough to detect a= nd blacklist attackers?

It's possible there are additional= asymmetric attack vectors I'm not thinking of, which is why I like thi= s as a general defense against a class of attacks. I mostly agree it's = mostly worthless when you have one server facing a botnet of 100,000 machin= es, but frankly that one server is a sitting duck regardless of countermeas= ures. OTOH, what if you have 20,000 servers facing such a botnet? Client pu= zzles effectively become a mechanism for enforcing distributed rate limitin= g, and could be used to dramatically raise the cost of mounting such an att= ack.

I have to think a lot more abo= ut the IoT/resource-constrained client problem, but I still don't think= the existence of clients that would be=C2=A0 by this scheme

Kyle
--001a1147ea5ed55b180536753a35-- From nobody Wed Jun 29 19:01:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5237012D7F8 for ; Wed, 29 Jun 2016 19:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zuu4IpYAycRc for ; Wed, 29 Jun 2016 19:01:29 -0700 (PDT) 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 B08A412D5D8 for ; Wed, 29 Jun 2016 19:01:29 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id o76so7101364qke.0 for ; Wed, 29 Jun 2016 19:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0HGVHWduSyKDpLuwh12hevWjk2qE7YRsiodpGqciXdk=; b=aKCS+Y7x6GUQCGYYN4YPJvmG+8m296ff0z77iOB2CCu9PZVewmcL3KNUJK8A1Yy5oJ 3W1W47e1H1b/Dp58DGZxAMi9YaqI2r3EZg8qxUC4wKoDW9anozjai21vJ+GSHXyZUq68 EPyntIXmmBLQsnjLV3En3Riw0scobBEJUXUJk= 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; bh=0HGVHWduSyKDpLuwh12hevWjk2qE7YRsiodpGqciXdk=; b=Wm3b8bdjEnLBlX3miEfDtVNSosok/c/sGdfWw0zz4RXyl/uP5IVtujYeWSF2Oip12D dCyYWIR8tS8QQZV+RRsWwzRSkCFI+4OwadrW/gBQKLK1b6wKwSNNRsQnM/icpNk8RJx5 NfT7Z504BECjejtPDB3PY9tWn21nQunAP2yEvE8gGfXgWcM/W6GqLT3ue6AflOX65lnG DO0E759kSR1FrdfuvZ2ou9NcS6UtIpnTy5swtCQp3zFQsmJT6GTZVhNkZY5OWqz62wrQ qrQlGvrw8KtHVorCKCamLVHzBpEgBT/XeIMuohTRXCiiGyUepIucUBiV6s1r7eZpATTu PRMA== X-Gm-Message-State: ALyK8tLOhKAx8cdWOmvSFuQsJFwNZAn0zvnNE/CXqlHEeFAGHkElnQ4RKef9ewn6RRXEkbHS5WwSIYWNzuP+yg== X-Received: by 10.55.24.215 with SMTP id 84mr15507799qky.51.1467252088904; Wed, 29 Jun 2016 19:01:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.80.66 with HTTP; Wed, 29 Jun 2016 19:01:28 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:7d87:9ebb:e00f:906b] In-Reply-To: References: From: Kyle Rose Date: Wed, 29 Jun 2016 22:01:28 -0400 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=001a113b9dc48e30100536753fb9 Archived-At: Cc: "" , Dmitry Khovratovich Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2016 02:01:31 -0000 --001a113b9dc48e30100536753fb9 Content-Type: text/plain; charset=UTF-8 Let's finish that last sentence: I have to think a lot more about the IoT/resource-constrained client problem, but I still don't think the existence of clients that would be denied service by this scheme renders the concept completely inapplicable. --001a113b9dc48e30100536753fb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let's finish that last sent= ence:

I have to think a lot more ab= out the IoT/resource-constrained client problem, but I still don't thin= k the existence of clients that would be d= enied service by this scheme renders the concept completely inapplicable.

--001a113b9dc48e30100536753fb9-- From nobody Wed Jun 29 19:36:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4178312DA78 for ; Wed, 29 Jun 2016 19:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKF31kRn_k35 for ; Wed, 29 Jun 2016 19:36:33 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE4312D7D1 for ; Wed, 29 Jun 2016 19:36:33 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id ADC9D33D1FD; Thu, 30 Jun 2016 02:36:32 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Kyle Rose References: From: Geoffrey Keating Date: 29 Jun 2016 19:36:32 -0700 In-Reply-To: Message-ID: Lines: 12 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: "" , Dmitry Khovratovich Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2016 02:36:34 -0000 Kyle Rose writes: > Let's finish that last sentence: > > I have to think a lot more about the IoT/resource-constrained client > problem, but I still don't think the existence of clients that would be > denied service by this scheme renders the concept completely inapplicable. Perhaps for the resource-constrained/IoT situation, what you want is to mostly be using a pre-shared key, track clients, and only make the suspicious (too many connections too fast) or new ones solve the puzzle. From nobody Wed Jun 29 21:42:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E90612D969 for ; Wed, 29 Jun 2016 21:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-JfUxSYYX9i for ; Wed, 29 Jun 2016 21:42:06 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0125.outbound.protection.outlook.com [65.55.169.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD64112D8F9 for ; Wed, 29 Jun 2016 21:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KQs13d+CFip9m6yWzfR8KWqBXciDmEBjIY2PWPm1ZsE=; b=DZVsPgcc38gvIRz0YwTKASQebulAhYD84tq/zT8akU6PAdHX61h1HX7n8BxPNpnWaH7r7dp4hsuAopHCH3UH27fBKpzsQeuROGhFQUI0N02bCHkTEUFGNe8UgsmaQK/bJzpkBwf3rCwd9sKwPYvZjvNszWWlR86LnUYhEICKfqY= 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 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.523.12; Thu, 30 Jun 2016 04:42:02 +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.0523.024; Thu, 30 Jun 2016 04:42:02 +0000 From: Christian Huitema To: Geoffrey Keating , Kyle Rose Thread-Topic: TLS client puzzles Thread-Index: AQHR0ng5bj+IEyqhH0+VJMcf+mrml6ABbXog Date: Thu, 30 Jun 2016 04:42:02 +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:659a:af7c:5a10:9c07] x-ms-office365-filtering-correlation-id: 38a6c67f-3c9c-4cd5-8e8f-08d3a0a0e195 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0654; 6:IM56ywF6Sd92gIbhNuCEDtOn2ULArdA5FVRvbMCfthpDIv/EQ0eQjcD1pFjZ5U92eEnCMF8vFeh0KeLu8qNBcFD2bL8w4mVRQWst/KblMKmrAMxyITjANTNeaROtkVpxELYssDARQed4pWTb0SgeinXL8l5dRh//O8kSbnzZADkpwUoJWHbcCMkYcPkGD/25MtEHK6uepxMsfkaUO3uOwMfDCnYDOiM8Gbj1Co4j5OXhMP0QLZ31jYiQ0ggsDuQONvNlEjK14vH+wWfni9ncLtyxB1z+MNe//V3319Yt40mwgJ1NCymuE8UedDqO4PASmTe1dABmMo+YDvLCHGWEC7E2C3Odf1z1s5Y93Hsyh44=; 5:66Q7BNd4IgBSoOrW508L2zbnUH+XnpAo7jSmYvkcd+QhVIB2aTAuw1innUgcnZ8OS9dvf6oHllacFMBKtzvTQxEBsz3gluA4RTtfe1waX8I4zT9LRfn+pfpebPE/Ca3NmKemDh/BumlfDkGh9Yeb9A==; 24:fnLQGYY0zBQPpb7ReBAo+2tFwzKsxGndEN5e7CBcUfjj1uOkbUA4kEnN/GuYkYIYKgb6DdAIaayQpUO2CHXKRsdlgJdSUguEogax+U/Y69E=; 7:R14T7GdSzKTc/apWdF7Bn51SyAeuOVDmLlXq+Ggek+k/n+EuidKAx5bfGCvJuFlduM3+5407ip2kZGqomMM1s6XDmgKfTSJqKBUhktBlu5jRelKNXxWbLC4pqiHIVnVHKVyIxYxghTG2G3COSg6U5bSIPccUc1ONaSzE0onQ4g3gGWPiz1ipw11P3Z7JAAmpPEKGy+88poyMbKZq5CVeeokmsXxZO/kr/p1lfJ7/eqbIEalmU1jVpFk1oVQ8coiopAw3/vFBKSjiHw0nNfLgrGq9wFglPjkM3uNP5/a66U4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0654; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0654; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0654; x-forefront-prvs: 0989A7979C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(24454002)(199003)(7846002)(5003600100003)(102836003)(97736004)(7736002)(93886004)(7696003)(8936002)(2950100001)(3480700004)(2900100001)(77096005)(2906002)(5001770100001)(10400500002)(6116002)(586003)(92566002)(50986999)(8990500004)(122556002)(33656002)(81166006)(189998001)(101416001)(54356999)(74316001)(10290500002)(81156014)(76176999)(9686002)(5005710100001)(76576001)(68736007)(4326007)(8676002)(10090500001)(86612001)(11100500001)(86362001)(19580405001)(5002640100001)(105586002)(106356001)(19580395003)(87936001)(99286002)(106116001)(3660700001)(3280700002)(305945005)(3826002); 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:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2016 04:42:02.8097 (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: "" , Dmitry Khovratovich Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2016 04:42:08 -0000 On Wednesday, June 29, 2016 7:37 PM, Geoffrey Keating wrote: >=20 > Kyle Rose writes: >=20 > > Let's finish that last sentence: > > > > I have to think a lot more about the IoT/resource-constrained client > > problem, but I still don't think the existence of clients that would be > > denied service by this scheme renders the concept completely inapplicab= le. >=20 > Perhaps for the resource-constrained/IoT situation, what you want is > to mostly be using a pre-shared key, track clients, and only make the > suspicious (too many connections too fast) or new ones solve the > puzzle. I am also a little worried that this can become a mechanism to DOS the clie= nts. Imagine an adversary capable of redirecting a client request, either b= y hacking the DNS or hacking a proxy. The hacked server can send the client= a puzzle, and force the client into spending some energy. And with the pro= posed extension, all that happens before the client has a chance to authent= icate the server. -- Christian Huitema From nobody Wed Jun 29 23:37:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101F712D5CE for ; Wed, 29 Jun 2016 23:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 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_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG6GR6nKBYpf for ; Wed, 29 Jun 2016 23:37:56 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010: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 5822512D5E8 for ; Wed, 29 Jun 2016 23:37:56 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id l188so48327738lfe.2 for ; Wed, 29 Jun 2016 23:37:56 -0700 (PDT) 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; bh=cnDwhdoRQVjOBGkH9HnG/4fBcijgL6qjEzxJZKZAx7k=; b=S6PQ1EKVXLEWtFkvlHVyNpvG0c0upXwE9EajxZlpva85dnWHkRv/63nMtPyAGv5EPm w6Njc1I+6JXm9LHZnawjRmBxL3TsRexVnw/bqy6Lv3/6xOM89xm1NxdHzfzmPd2yS432 q7wrG3u990R2AYPrIJo5FiPiyK8EO32QJ5x/zgxOF2rzRn73kRWbgwe5fkO7o+jj+D5n DJsNBGQmCX5Q8cEK3KBpMUiMNJqMGkIQd3O+4g31JQjUlxcUl0F4hYvy2yeKe+bZ0Jlf piIT29+CkyBHMiskkP9T147pm56M2DASuK1ZgVBjwdYfXwakMm6KylBzn5MacE/uUohh aP4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version; bh=cnDwhdoRQVjOBGkH9HnG/4fBcijgL6qjEzxJZKZAx7k=; b=my/kDQJ5emsojFXbNUkpn1wop4WYg5i1RD/q03fThrjkqhGbL3kscr6c/ItEMcywuR MV9I9fxUHraFCJqctgoJwKQQqueu7Yb4sZp0sx6TWRQETKaV6KgWlqDYcd3/BtuCOTrs wCwF5pmqR5o95tBErqFQoTNIaeKiP2eyCyhJKigWciyVLF4XjDKrBYx0MOsNtn3VGwub T84xMarTQiTVdbhCDoAxkFbopAr0gs2xZwCS0q6muW+vT7q+CWYTF6V9HUrwKujbwpaB iX5VMVJANF4STHueHU6SDVxlE7OzaZhDUueqfhVzqbjpx77MfCAfomo1y2Wj0fBe/hsa 62cQ== X-Gm-Message-State: ALyK8tKODAHSxhMMHqdZToS9JbUpmUTa3YZ6BToMdVzwS1zpHXPxSPWS5f+9Vea6m+OQrw== X-Received: by 10.46.0.16 with SMTP id 16mr3849903lja.56.1467268674546; Wed, 29 Jun 2016 23:37:54 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 76sm1275841lfu.26.2016.06.29.23.37.53 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Wed, 29 Jun 2016 23:37:53 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Kyle Rose" , "Christian Huitema" References: Date: Thu, 30 Jun 2016 09:37:52 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_190A_01D1D2B3.12BEAD00" 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, Dmitry Khovratovich Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2016 06:37:59 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_190A_01D1D2B3.12BEAD00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, you may be also interested in similar work done in ipsecme group: https://www.ietf.org/id/draft-ietf-ipsecme-ddos-protection-06.txt The draft describes various defnse methods against (D)DoS attacks in = IKEv2 and, in particular, introduces puzzles. We tried to specify using = puzzles in such a way that their negative impact on legitimate (or even = unsupporting) initiators be as small as possible (although of course it cannot be completely = avoided). The draft is in WGLC now. Regards, Valery Smyslov. On Wed, Jun 29, 2016 at 5:41 PM, Christian Huitema = wrote: On Wednesday, June 29, 2016 2:08 PM, Kyle Rose wrote: > > Raising the cost of requests has a similar problem in that you're = punishing > every client, but in doing so you do allow all clients capable of = absorbing > the increased cost (e.g., memory, computing power) to get access = to the > resources they need if the user is willing to accept that cost = (e.g., energy, > latency). The obvious issue with the "proof of work" defense against DDOS is = that the bot nets can do more work than many legitimate clients. The = puzzle approach will cut off the least capable legitimate clients, such = as old phones or IOT devices. It will not cut off the PC enrolled in a = bot net. It will merely slow it down a little. But then, you could have = the same effect by just delaying the response and enforcing one = connection per client. I agree with you that the above seems equivalent in theory, but in = practice it might not be feasible. The biggest obstacle seems to be enforcing one connection per client. = Let's say rate limiting on a per-client basis doesn't work because many = of your clients are behind a NAT; or because the attacker is using IPv6 = and generates a ton of temporary addresses that make the situation = indistinguishable from many legitimate clients in the same subnet. So = you can either serve one (or a small N) of them at a time, or you drop = that restriction and allow a single client to mount an asymmetric = attack. Alternatively, what if you have lots of geographically-distributed = servers and can't share client rate limiting state among them quickly = enough to detect and blacklist attackers? It's possible there are additional asymmetric attack vectors I'm not = thinking of, which is why I like this as a general defense against a = class of attacks. I mostly agree it's mostly worthless when you have one = server facing a botnet of 100,000 machines, but frankly that one server = is a sitting duck regardless of countermeasures. OTOH, what if you have = 20,000 servers facing such a botnet? Client puzzles effectively become a = mechanism for enforcing distributed rate limiting, and could be used to = dramatically raise the cost of mounting such an attack. I have to think a lot more about the IoT/resource-constrained client = problem, but I still don't think the existence of clients that would be = by this scheme Kyle -------------------------------------------------------------------------= ----- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ------=_NextPart_000_190A_01D1D2B3.12BEAD00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi,
 
you may be also interested in similar work done in = ipsecme=20 group:
 
 
The draft describes various defnse methods against=20 (D)DoS attacks in IKEv2
and, in particular, introduces puzzles. We = tried to=20 specify using puzzles
in such a way that their negative impact on = legitimate (or=20 even unsupporting) initiators
be as small as possible (although of course it = cannot be=20 completely avoided).
The draft is in WGLC now.
 
Regards,
Valery Smyslov.
 
On Wed, Jun 29, 2016 at 5:41 PM, Christian Huitema <huitema@microsoft.com> wrote:
On Wednesday, June 29, 2016 2:08 PM, Kyle = Rose=20 wrote:
>
> Raising the cost of requests has a similar = problem in=20 that you're punishing
> every client, but in doing so you do = allow all=20 clients capable of absorbing
> the increased cost (e.g., = memory,=20 computing power) to get access to the
> resources they need if = the=20 user is willing to accept that cost (e.g., energy,
>=20 latency).

The obvious issue with the "proof of work" = defense=20 against DDOS is that the bot nets can do more work than many = legitimate=20 clients. The puzzle approach will cut off the least capable = legitimate=20 clients, such as old phones or IOT devices. It will not cut off the = PC=20 enrolled in a bot net. It will merely slow it down a little. But = then, you=20 could have the same effect by just delaying the response and = enforcing one=20 connection per client.

I agree with you that the above seems equivalent in theory, = but in=20 practice it might not be feasible.

The biggest obstacle seems to be enforcing one connection per = client.=20 Let's say rate limiting on a per-client basis doesn't work because = many of=20 your clients are behind a NAT; or because the attacker is using IPv6 = and=20 generates a ton of temporary addresses that make the situation=20 indistinguishable from many legitimate clients in the same subnet. So = you can=20 either serve one (or a small N) of them at a time, or you drop that=20 restriction and allow a single client to mount an asymmetric=20 attack.

Alternatively, what if you have lots of=20 geographically-distributed servers and can't share client rate = limiting state=20 among them quickly enough to detect and blacklist = attackers?

It's=20 possible there are additional asymmetric attack vectors I'm not = thinking of,=20 which is why I like this as a general defense against a class of = attacks. I=20 mostly agree it's mostly worthless when you have one server facing a = botnet of=20 100,000 machines, but frankly that one server is a sitting duck = regardless of=20 countermeasures. OTOH, what if you have 20,000 servers facing such a = botnet?=20 Client puzzles effectively become a mechanism for enforcing = distributed rate=20 limiting, and could be used to dramatically raise the cost of mounting = such an=20 attack.

I have to think a lot more about the=20 IoT/resource-constrained client problem, but I still don't think the = existence=20 of clients that would be  by this scheme

Kyle

_______________________________________________
TLS mailing=20 = list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
------=_NextPart_000_190A_01D1D2B3.12BEAD00-- From nobody Thu Jun 30 01:23:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B1A12D624 for ; Thu, 30 Jun 2016 01:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZHaWoyRr5Ed for ; Thu, 30 Jun 2016 01:23:53 -0700 (PDT) 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 29C7012D536 for ; Thu, 30 Jun 2016 01:23:53 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id r201so106902434wme.1 for ; Thu, 30 Jun 2016 01:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r/MVjKbI6J68SlZbyZlxT2uZ3BVk4mfZYDMOZa/+bOs=; b=vHixMdK+jbljLDhtNJr24lgZj0XQ+tD5UvxTPa4TXAVtgdK4vxOFWDlZr+Ot23rFwd AkOJ7oJoefRQLtOLXTREGNMfUk5VqDQpNO+sOX/WH1ODLFImmsmn5j8O1OmLpnHKYtdZ S0k/x48rWPSBLeDdEmAOZ+bueSeY2HXAgzVWIcCxNno+/BWAmgatqiNNpzc/As5O4xDW wjG1wM0F6L08W4lrT4uu3hBnbucgdLSIC7usf3cvIA5qGFRZo7tdU/wt3eeAM8W/vh2a q6lw0xolyPPDe8cMwpI4L2xA843GQLzgap+ZXn0vnG6RyHhiRnBlrcIDtRv3xMg3cPUA oBSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r/MVjKbI6J68SlZbyZlxT2uZ3BVk4mfZYDMOZa/+bOs=; b=Tq48JDU6csnvIUF0TWt58g2DFMml5Nffk+Pq4p2nr0SN2invw+sxLJIY9IhpqXKHOC EYfHGRloqaRzlBdNp+4KKY5uhRCuU5E6Uj1q9IQ6XwErEumzFnfcu69f+h7IVgh343X3 H6pHjAxBZ9+GgWKn4ovF2/cUQoiTAwzIpyF8vou6EnckxELLo5eI5IlvlRqlsRrkoZg3 3yS+u+wv6W3143NIy9Y3X/r5o+Sp8zkeeCgUQhZCpPZoCYXd0qquHJxBHtiXPPSVfp2f OnXT5JGJDCvkd71SG87XwQ8W1OOjUCciqIZ6tFu18zwkx8/rlLDdBzeAHNrg8xM/fThw oZMw== X-Gm-Message-State: ALyK8tKg8OvlV+4MZKDZWiDQ33oe1pcs/HQLtblnT1uVEq/OuXqW0+4UbzfZfDyS7XGXiQ== X-Received: by 10.28.67.69 with SMTP id q66mr24800164wma.81.1467275031631; Thu, 30 Jun 2016 01:23:51 -0700 (PDT) Received: from [172.24.251.18] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id u4sm2009750wjz.4.2016.06.30.01.23.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 30 Jun 2016 01:23:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Thu, 30 Jun 2016 11:23:47 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Smith X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Dmitry Khovratovich , "" Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2016 08:23:55 -0000 > On 29 Jun 2016, at 10:25 PM, Brian Smith wrote: >=20 > Dmitry Khovratovich wrote: >> It allows cheap and memoryless verification by the server even though = the >> puzzle solving guaranteely requires dozens of MB of RAM from a client >=20 > I feel like this is impractical simply because lots of people are > building HTTPS clients that don't even have dozens of MB of RAM total. > I think we should avoid doing anything that requires the client to > have more than ~16KB of memory total to devote to TLS stuff. > Otherwise, we force the internet to have an architecture where all > small devices require a smart proxy to solve these puzzles for them > and do other things. Hi, Brian. Having clients commit resources to solve puzzles is always a balancing = act between the capabilities of legitimate clients and those of the = attackers. With CPU-intensive puzzles the attackers tend to be fast = desktops and servers, while the legitimate clients could be as weak as a = smart-object or as powerful as a server. It=E2=80=99s hard to find good = parameters that will allow the oldest phone in while slowing the = attacker down significantly. The same, as you pointed out, is true for = RAM-intensive puzzles. For the web the legitimate clients fall into two categories: Desktops = and laptops on the one hand, and mobile phones on the other. For = CPU-intensive puzzles their capabilities are far apart, so you=E2=80=99d = have to tune the puzzle to the capabilities of the weakest phone, or = else accept that phones are cut off during a severe DDoS attack. With = RAM, however, the differences are less pronounced. Both kinds of = legitimate clients can afford to devote dozens of MB of RAM. The same is = not true for IoT, but I=E2=80=99m talking about the real web here, not = data services over HTTPS. I think for this particular case RAM-intensive puzzles make sense. Yoav From nobody Thu Jun 30 08:17:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2045A12D185 for ; Thu, 30 Jun 2016 08:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRakYJV-5vIW for ; Thu, 30 Jun 2016 08:17:45 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c: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 4DC5A12D0B6 for ; Thu, 30 Jun 2016 08:07:58 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id m127so54060352vkb.3 for ; Thu, 30 Jun 2016 08:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IL17pg9AE4zWBVt+US5ot0m+K9Ju35jKZUFCWfRQVLA=; b=XOCw0wkiBCN4pp1mxR4Ra7GwkHuHw9hbRgWJxCYuo0JjBtHL0mXee40kKPonNTyz7f YbXtuT7gvngvGXIz0YuoMH2QmREAb8AwgNYUW6q+C0xkKZjF6gHPYBeJPt8E3GVbA18t Rwo2CVBTAtpd/Xpc6lYXkCZBz484s3pll3+q867w2MjBsxb5xfIPzNFTBOOieX6OkkTI ODgKdKAzUMAWOB5AOJ15ajs+BPMwUfSJdrE+yda0ttrMv5EJgaawQ8MRiv4bqyIZscJy avFJlV9mILbxj7mfQHvHecTEPoNmfQLis6JAcrFp1q09/VJj7L7cQ+0a5i+lAzs19b82 dLFw== 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; bh=IL17pg9AE4zWBVt+US5ot0m+K9Ju35jKZUFCWfRQVLA=; b=YKux3FmgGLybZtb0/B+5MLaj6HcFiMvJwr2QX1thWjo+Q+mXK3B4oM6Ufmjfx7bPn5 GBbDL1wTtLWG83tB5rHObaEbzgWDC7V3qXMmLLTHd8vCc4lmf3bFRNMtL56L0ZvrzxkE rVJhGZDrYcXPTJbqcRI9wEkfFQkxmGFwgYziERHJYi4SmjStyDj5D18+9a+6klNefXlN 7MLO69D82cnjBN7KDc/81NZYARUF4rV5Ni8Hjzdoe+koZzS82Ve94C/ZvGwEUmZTGucT VtSZDTC5KHRE9Z7s1/5hSnJV+rL6NMuuwkSpDqCS37a5G/dZcJKKTuYXQ3UwDpPj2ZPS 38vA== X-Gm-Message-State: ALyK8tI03v2v/dL54m/bNGNaiuAr1/9SFqmvswkK/lJ2MJMzlXXr2eHfm/IHEq4H7BHA1kpJVKlcQsi2iYl1IRPh X-Received: by 10.159.40.37 with SMTP id c34mr5727900uac.79.1467299277188; Thu, 30 Jun 2016 08:07:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.200.65 with HTTP; Thu, 30 Jun 2016 08:07:56 -0700 (PDT) In-Reply-To: References: From: Bill Cox Date: Thu, 30 Jun 2016 08:07:56 -0700 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=94eb2c04812832dbc80536803cb9 Archived-At: Cc: "" , Dmitry Khovratovich Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2016 15:17:47 -0000 --94eb2c04812832dbc80536803cb9 Content-Type: text/plain; charset=UTF-8 Equihash looks like a nice advance, so kudos to Dmitry's team. So long as we're on this topic, I'll mention an alternative that addresses some of your concerns. I do not recommend making it an official part of TLS, as I feel that TLS is already vastly too complex. However, this algorithm is very cool: Makwa is a "recommended" algorithm from the password-hashing contest. It is a proof-of-work algorithm with fast verification, but is not memory-hard. However, that seems OK, since Makwa supports "delegation". An IoT device can ask any Makwa hashing provider on the Internet to do the proof of work for it, and the result is as secure as if the IoT device had done it. This solves the concern about leaving under-powered devices behind, while aiding in DDoS defense. If widely adopted, with ASIC implementations, it would also defeat botnets. ASICs would many times more efficient than CPUs at Makwa, IIRC, about 4000X in my last analysis. Even botnets would have difficulty competing with a legit ASIC Makwa provider. My own dumb-idea related to Makwa is to use it as a PoW in a block-chain based crypto-coin. If miners are going to waste crazy amounts of electricity mining anyway, at least they could help defeat DDoS attacks while they are at it. This might also create a method for IoT devices to pay for the PoW service in nano transactions. No way would I ever want such a beast bolted into TLS :> Maybe as a DDoS extension API in OpenSSL? Bill --94eb2c04812832dbc80536803cb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Equihash looks like a nice adva= nce, so kudos to Dmitry's team.=C2=A0 So long as we're on this topi= c, I'll mention an alternative that addresses some of your concerns.=C2= =A0 I do not recommend making it an official part of TLS, as I feel that TL= S is already vastly too complex.=C2=A0 However, this algorithm is very cool= :

Makwa is a &quo= t;recommended" algorithm from the password-hashing contest.=C2=A0 It i= s a proof-of-work algorithm with fast verification, but is not memory-hard.= =C2=A0 However, that seems OK, since Makwa supports "delegation".= =C2=A0 An IoT device can ask any Makwa hashing provider on the Internet to = do the proof of work for it, and the result is as secure as if the IoT devi= ce had done it.=C2=A0 This solves the concern about leaving under-powered d= evices behind, while aiding in DDoS defense.

If widely adopted, with ASIC impleme= ntations, it would also defeat botnets.=C2=A0 ASICs would many times more e= fficient than CPUs at Makwa, IIRC, about 4000X in my last analysis.=C2=A0 E= ven botnets would have difficulty competing with a legit ASIC Makwa provide= r.

My = own dumb-idea related to Makwa is to use it as a PoW in a block-chain based= crypto-coin.=C2=A0 If miners are going to waste crazy amounts of electrici= ty mining anyway, at least they could help defeat DDoS attacks while they a= re at it.=C2=A0 This might also create a method for IoT devices to pay for = the PoW service in nano transactions.

<= /div>
No way would I ever want such a beast bolte= d into TLS :> =C2=A0Maybe as a DDoS extension API in OpenSSL?

Bill
--94eb2c04812832dbc80536803cb9-- From nobody Thu Jun 30 16:25:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A62612B04F for ; Thu, 30 Jun 2016 16:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqLr9coBAkGr for ; Thu, 30 Jun 2016 16:25:21 -0700 (PDT) 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 1320D12B043 for ; Thu, 30 Jun 2016 16:25:18 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id s66so88204594oif.1 for ; Thu, 30 Jun 2016 16:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZdVtWbpvEqJSR1r4A3V2k4D+XLyUNnytGkG8lVNQTU4=; b=LTDG/TbfhRke8tawf4tXi+V7JfyGbKy+xq3fa2PnL3p1g4+PyEw6xtpNddMw8qx5eS H2xHuDoj/F7XkC0jYh03xIJvWCj3kZ2U6J6BWMIwds6+8YSaVnANtiVZMabjVVHaslaR NCh/j1Rpy4jW9KPNn+jpuOeHh+Z7AqSFT/+A4jM61EjlgglrjBwEiu+fvaU7sCS6H4RT rSChz9bCWjIXjVp8jyH1UFmv7KgZ0eWzorO6ILURKAcf4VbT/MXTpOsuz6i6XrlNQhm8 mP/F0FminRFCBSwNngA43BJghRzmfCErXVpNJwnNdEOLcPhgCDd/tuecpePtN69Aq9i9 SWLg== 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:cc; bh=ZdVtWbpvEqJSR1r4A3V2k4D+XLyUNnytGkG8lVNQTU4=; b=Ry6OBdiBoSRz0AVIQQFtxcFqeuDMZnd2gTKJtZsd9IdZ5GkXYSGYminmOiVTSoNK8j DOEhW0p3WL8Yc2A9k446EygBMthEfSz1QbKa9kJk+nQ/PSYo3tTkTWeRNWfuPOfCj1ng v7MBj0/oC00HuJhoPXO9nMaabEg/IWrwsMIhFSrZ9ItY8u3L+LbTxqqHMQWEzu7byugh UXItlfqBrJ1exwymtliltDuxyX+8SNio4C3w+av554xSJ3e2wThnLVIaoZNhAUOo13cl ckLBk0u6SgonarDqfaAXw/85uGqQL4qQTCRWAE/2T1asKQkIJdy/vIdq9F1yLHS66nRT xdAg== X-Gm-Message-State: ALyK8tI0ESHIbNV+BqzWxGBWa6prdff1qi/1HN9s986PLXQBqycXdMRtYbd+HvHwF1i/82X5 X-Received: by 10.157.26.87 with SMTP id u23mr10893118otu.169.1467329118075; Thu, 30 Jun 2016 16:25:18 -0700 (PDT) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com. [209.85.218.48]) by smtp.gmail.com with ESMTPSA id h35sm4206597otb.31.2016.06.30.16.25.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jun 2016 16:25:17 -0700 (PDT) Received: by mail-oi0-f48.google.com with SMTP id u201so88142604oie.0 for ; Thu, 30 Jun 2016 16:25:16 -0700 (PDT) X-Received: by 10.157.4.130 with SMTP id 2mr12050376otm.122.1467329116683; Thu, 30 Jun 2016 16:25:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Adrian Date: Thu, 30 Jun 2016 23:25:06 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Brian Smith , Dmitry Khovratovich Content-Type: multipart/alternative; boundary=94eb2c09e008c4c6dd0536872e0d Archived-At: Cc: "" Subject: Re: [TLS] TLS client puzzles X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2016 23:25:24 -0000 --94eb2c09e008c4c6dd0536872e0d Content-Type: text/plain; charset=UTF-8 On Wed, Jun 29, 2016 at 12:25 PM Brian Smith wrote: > Dmitry Khovratovich wrote: > > It allows cheap and memoryless verification by the server even though the > > puzzle solving guaranteely requires dozens of MB of RAM from a client > > I feel like this is impractical simply because lots of people are > building HTTPS clients that don't even have dozens of MB of RAM total. > I think we should avoid doing anything that requires the client to > have more than ~16KB of memory total to devote to TLS stuff. > Otherwise, we force the internet to have an architecture where all > small devices require a smart proxy to solve these puzzles for them > and do other things. > > I have to second Brian's opinion---it's difficult enough to get embedded devices to use HTTPS already. Requiring dozens of megabytes of memory will make HTTPS impossible for these devices in many cases. > Cheers, > Brian > -- > https://briansmith.org/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c09e008c4c6dd0536872e0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed= , Jun 29, 2016 at 12:25 PM Brian Smith <brian@briansmith.org> wrote:
Dmitry Khovratovich <khovratovich@gmail.com> wrote:
> It allows cheap and memoryless verification by the server even though = the
> puzzle solving guaranteely requires dozens of MB of RAM from a client<= br>
I feel like this is impractical simply because lots of people are
building HTTPS clients that don't even have dozens of MB of RAM total.<= br> I think we should avoid doing anything that requires the client to
have more than ~16KB of memory total to devote to TLS stuff.
Otherwise, we force the internet to have an architecture where all
small devices require a smart proxy to solve these puzzles for them
and do other things.


I have to second Brian's opinion--= -it's difficult enough to get embedded devices to use HTTPS already. Re= quiring dozens of megabytes of memory will make HTTPS impossible for these = devices in many cases.
=C2=A0
Cheers,
Brian
--
ht= tps://briansmith.org/

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